[strongSwan] StrongSwan w/ multiple local subnets.
Brian Topping
brian.topping at gmail.com
Sat Jun 20 07:10:20 CEST 2020
I do the same thing with OSPF (with BIRD 2).
I’m going to take a guess that StrongSWAN is working fine and your router is not sensing the transition of it, so it doesn’t know when (or where) to route. But I can’t exactly tell if you are setting up interfaces with an updown script, I don’t see them here. See https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux <https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux> and https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/_updown/_updown.in <https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/_updown/_updown.in>.
After you have interfaces working properly, have your OSPF configured against the interfaces (I just use something like `vti*` wildcard so I can name them anything) and you should see correct behavior.
Last point of note, I just define `0.0.0.0/0` on left/rightsubnet. If your deployment gets supersized, you won’t want to be going back and updating networks on every gateway, though you will probably want to do that from LDAP for road warriors.
> On Jun 19, 2020, at 10:53 PM, TomK <tomkcpr at mdevsys.com> wrote:
>
> On 6/19/2020 10:56 PM, Brian Topping wrote:
>> Sounds like you’re unable to look at traffic on both sides. Unless you’re looking closely at the logs and know what’s happening, it’s hard to debug. It also looks as if you’ve rather heavily sanitized the console logs, for instance the ping destination.
>> This line concerns me:
>>> Jun 19 19:57:11 14[KNL] error installing route with policy 10.3.0.0/24 === 10.10.0.0/24 out
>> If your are coming from or going to 100.100.100.100 and using transport instead of tunnel, these routes being installed are wrong, which becomes a configuration issue.
>> Best way to post is to take the console output verbatim, then replace the first two octets of every IP address you want to sanitize with unique letters so the addresses can be distinguished. Easier if you can put the content into something like pastebin or gist instead of mailing to the list for viewing purposes.
>> Sent from my iPhone
>>> On Jun 19, 2020, at 19:28, TomK <tomkcpr at mdevsys.com> wrote:
>>>
>>> Jun 19 19:57:11 14[KNL] error installing route with policy 10.3.0.0/24 === 10.10.0.0/24 out
>
> Thank you. Attached the logs.
>
> https COLON //www DOT microdevsys DOT com/WordPressFiles/charon.log
> https COLON //www DOT microdevsys DOT com/WordPressFiles/var-log-messages.txt
>
>
> Config files:
>
> root at DD-WRT:~# cat /opt/etc/ipsec.conf
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
> # strictcrlpolicy=yes
> # uniqueids = no
>
> # Add connections here.
>
> conn REMOTE-VLAN1
> authby=secret
> auto=start
> type=tunnel
> keyexchange=ikev2
> keylife=3600s
> ikelifetime=28800s
> rekey=yes
> rekeymargin=3m
> keyingtries=1
> mobike=no
> dpdaction=none
> lifebytes=102400000
> left=100.100.100.100 # IP address of your on-premises gateway
> leftsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24 # Home LAB - Local
> # leftnexthop=%defaultroute
> right=123.123.123.123 # Remote VPN gateway IP address
> rightsubnet=10.10.0.0/24,10.10.1.0/24,10.10.2.0/24,10.10.3.0/24,10.10.4.0/24 # Remote network subnet defined in public cloud
> ike=aes256-sha1-modp1024
> esp=aes256-sha1
>
> root at DD-WRT:~#
>
>
>
> root at DD-WRT:~# cat /opt/etc/strongswan.conf
> # strongswan.conf - strongSwan configuration file
> #
> # Refer to the strongswan.conf(5) manpage for details
> #
> # Configuration changes should be made in the included files
> # Verbosity levels
> # -1: Absolutely silent
> # 0: Very basic auditing logs, (e.g. SA up/SA down)
> # 1: Generic control flow with errors, a good default to see whats going on
> # 2: More detailed debugging control flow
> # 3: Including RAW data dumps in Hex
> # 4: Also include sensitive material in dumps, e.g. keys
> charon {
> load_modular = yes
> plugins {
> include strongswan.d/charon/*.conf
> }
> filelog {
> charon {
> path = /opt/tmp/charon.log
> time_format = %b %e %T
> append = no
> default = 2 # in case troubleshoot is required switch this to 2
> }
> stderr {
> ike = 2 # in case troubleshoot is required switch this to 2
> knl = 3 # in case troubleshoot is required switch this to 3
> ike_name = yes
> }
> }
> syslog {
> # enable logging to LOG_DAEMON, use defaults
> daemon {
> }
> # minimalistic IKE auditing logging to LOG_AUTHPRIV
> auth {
> default = 2 # in case troubleshoot is required switch this to 2
> ike = 2 # in case troubleshoot is required switch this to 2
> }
> }
> }
> include strongswan.d/*.conf
> root at DD-WRT:~#
>
>
> root at DD-WRT:~# ipsec statusall
> Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.4.190, armv7l):
> uptime: 28 seconds, since Jun 19 23:04:51 2020
> malloc: sbrk 892928, mmap 0, used 493392, free 399536
> worker threads: 6 of 16 idle, 6/0/4/0 working, job queue: 0/0/0/0, scheduled: 4
> loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revoca tion constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp gmpdh curve255 19 agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-libipsec kernel-netlink resolve socket-default socket-dynamic farp stroke vici smp updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xau th-eap dhcp whitelist led duplicheck addrblock unity
> Listening IP addresses:
> 100.100.100.100
> 192.168.0.6
> 192.168.45.1
> 192.168.75.1
> 10.1.1.1
> Connections:
> AZURE-VLAN1: 100.100.100.100...123.123.123.123 IKEv2
> AZURE-VLAN1: local: [100.100.100.100] uses pre-shared key authentication
> AZURE-VLAN1: remote: [123.123.123.123] uses pre-shared key authentication
> AZURE-VLAN1: child: 192.168.0.0/24 10.0.0.0/24 10.1.0.0/24 10.2.0.0/24 10.3.0.0/24 === 10.10.0.0/24 10.10.1.0 /24 10.10.2.0/24 10.10.3.0/24 10.10.4.0/24 TUNNEL
> Security Associations (1 up, 0 connecting):
> AZURE-VLAN1[1]: ESTABLISHED 27 seconds ago, 100.100.100.100[100.100.100.100]...123.123.123.123[123.123.123.123]
> AZURE-VLAN1[1]: IKEv2 SPIs: 5464f1e04af780fd_i* fa01060f92607d17_r, pre-shared key reauthentication in 7 hours
> AZURE-VLAN1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
> root at DD-WRT:~#
>
>
> root at DD-WRT:~# opkg list-installed|grep -Ei strongswan
> strongswan - 5.8.2-1
> strongswan-charon - 5.8.2-1
> strongswan-ipsec - 5.8.2-1
> strongswan-libtls - 5.8.2-1
> strongswan-mod-addrblock - 5.8.2-1
> strongswan-mod-aes - 5.8.2-1
> strongswan-mod-af-alg - 5.8.2-1
> strongswan-mod-agent - 5.8.2-1
> strongswan-mod-attr - 5.8.2-1
> strongswan-mod-attr-sql - 5.8.2-1
> strongswan-mod-blowfish - 5.8.2-1
> strongswan-mod-ccm - 5.8.2-1
> strongswan-mod-cmac - 5.8.2-1
> strongswan-mod-constraints - 5.8.2-1
> strongswan-mod-coupling - 5.8.2-1
> strongswan-mod-ctr - 5.8.2-1
> strongswan-mod-curl - 5.8.2-1
> strongswan-mod-curve25519 - 5.8.2-1
> strongswan-mod-des - 5.8.2-1
> strongswan-mod-dhcp - 5.8.2-1
> strongswan-mod-dnskey - 5.8.2-1
> strongswan-mod-duplicheck - 5.8.2-1
> strongswan-mod-eap-identity - 5.8.2-1
> strongswan-mod-eap-md5 - 5.8.2-1
> strongswan-mod-eap-mschapv2 - 5.8.2-1
> strongswan-mod-eap-radius - 5.8.2-1
> strongswan-mod-eap-tls - 5.8.2-1
> strongswan-mod-farp - 5.8.2-1
> strongswan-mod-fips-prf - 5.8.2-1
> strongswan-mod-gcm - 5.8.2-1
> strongswan-mod-gcrypt - 5.8.2-1
> strongswan-mod-gmp - 5.8.2-1
> strongswan-mod-gmpdh - 5.8.2-1
> strongswan-mod-ha - 5.8.2-1
> strongswan-mod-hmac - 5.8.2-1
> strongswan-mod-kernel-libipsec - 5.8.4-1
> strongswan-mod-kernel-netlink - 5.8.2-1
> strongswan-mod-ldap - 5.8.2-1
> strongswan-mod-led - 5.8.2-1
> strongswan-mod-load-tester - 5.8.2-1
> strongswan-mod-md4 - 5.8.2-1
> strongswan-mod-md5 - 5.8.2-1
> strongswan-mod-mysql - 5.8.2-1
> strongswan-mod-nonce - 5.8.2-1
> strongswan-mod-openssl - 5.8.2-1
> strongswan-mod-pem - 5.8.2-1
> strongswan-mod-pgp - 5.8.2-1
> strongswan-mod-pkcs1 - 5.8.2-1
> strongswan-mod-pkcs11 - 5.8.2-1
> strongswan-mod-pkcs12 - 5.8.2-1
> strongswan-mod-pkcs7 - 5.8.2-1
> strongswan-mod-pkcs8 - 5.8.2-1
> strongswan-mod-pubkey - 5.8.2-1
> strongswan-mod-random - 5.8.2-1
> strongswan-mod-rc2 - 5.8.2-1
> strongswan-mod-resolve - 5.8.2-1
> strongswan-mod-revocation - 5.8.2-1
> strongswan-mod-sha1 - 5.8.2-1
> strongswan-mod-sha2 - 5.8.2-1
> strongswan-mod-smp - 5.8.2-1
> strongswan-mod-socket-default - 5.8.2-1
> strongswan-mod-socket-dynamic - 5.8.2-1
> strongswan-mod-sql - 5.8.2-1
> strongswan-mod-sqlite - 5.8.2-1
> strongswan-mod-sshkey - 5.8.2-1
> strongswan-mod-stroke - 5.8.2-1
> strongswan-mod-test-vectors - 5.8.2-1
> strongswan-mod-unity - 5.8.2-1
> strongswan-mod-updown - 5.8.2-1
> strongswan-mod-vici - 5.8.2-1
> strongswan-mod-whitelist - 5.8.2-1
> strongswan-mod-x509 - 5.8.2-1
> strongswan-mod-xauth-eap - 5.8.2-1
> strongswan-mod-xauth-generic - 5.8.2-1
> strongswan-mod-xcbc - 5.8.2-1
> strongswan-pki - 5.8.2-1
> strongswan-scepclient - 5.8.2-1
> strongswan-swanctl - 5.8.2-1
> root at DD-WRT:~#
>
>
> Firewall config. I had lines like this:
>
>
> iptables -I FORWARD -s 10.10.0.0/24 -d 192.168.0.0/24 -j ACCEPT
> iptables -I INPUT -p icmp -s 10.10.0.0/24 -d 192.168.0.0/24 -j ACCEPT
>
>
> But when I took them out, it made no difference at all. So I effectively have nothing for StrongSwan in my local F/W configuration at the moment.
>
>
> 100.100.100.100 is my local environment. 123.123.123.123 is a remote cloud provider, Azure. I'm also running OSPF on the DD-WRT LOCAL routers so none of my routers are configured as Gateways as typically would be the case. OSPF handles my local routing. Works like a charm.
>
>
> ISSUE DESCRIPTION ------------------------------
>
>
> When I try to ping the remote cloud VM on 10.10.0.4 from my local router that I'm using for StrongSwan:
>
>
> root at DD-WRT:~# ping 10.10.0.4
> PING 10.10.0.4 (10.10.0.4): 56 data bytes
>
>
> Nothing happens. There is no activity on the ipsec0 interface at all:
>
>
> # tcpdump -i ipsec0 -s 0 -n arp or icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
> (EMPTY)
>
>
> At this point I SSH to the cloud VM via the public IP and initiate a ping in return to any IP on my LOCAL on-PREM environment VLAN 192.168.0.0/24 and this works fine:
>
>
> [root at cm-azure-wn03 ~]# ping 192.168.0.154
> PING 192.168.0.154 (192.168.0.154) 56(84) bytes of data.
> (short pause)
> 64 bytes from 192.168.0.154: icmp_seq=4 ttl=63 time=46.5 ms
> 64 bytes from 192.168.0.154: icmp_seq=5 ttl=63 time=48.5 ms
> 64 bytes from 192.168.0.154: icmp_seq=6 ttl=63 time=46.6 ms
>
>
> SSH and everything else works great from REMOTE to LOCAL as well.
>
>
> [root at cm-azure-wn03 ~]# ip route show
> default via 10.10.0.1 dev eth0 proto dhcp metric 100
> 10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.4 metric 100
> 168.63.100.16 via 10.10.0.1 dev eth0 proto dhcp metric 100
> 169.254.100.254 via 10.10.0.1 dev eth0 proto dhcp metric 100
> [root at cm-azure-wn03 ~]#
>
>
> and sure enough, traffic is registered on the tcpdump running against the ipsec01 interface when pinging from REMOTE to LOCAL, as expected:
>
>
> root at DD-WRT:~# tcpdump -i ipsec0 -s 0 -n arp or icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
> 23:46:03.793056 IP 10.10.0.4 > 192.168.0.154: ICMP echo request, id 7426, seq 1, length 64
> 23:46:03.796663 IP 192.168.0.154 > 10.10.0.4: ICMP echo reply, id 7426, seq 1, length 64
> 23:46:04.869369 IP 10.10.0.4 > 192.168.0.154: ICMP echo request, id 7426, seq 2, length 64
> 23:46:04.872168 IP 192.168.0.154 > 10.10.0.4: ICMP echo reply, id 7426, seq 2, length 64
>
>
> So from REMOTE to LOCAL it works fine. But now here's where it get's interesting. I'll go back to the LOCAL terminal whence I started the first ping and repeat the ping once more:
>
>
> root at DD-WRT:~# ping 10.10.0.4
> PING 10.10.0.4 (10.10.0.4): 56 data bytes
>
>
> And now I see ICMP echo requests going out and registering on ipsec0.
>
>
> # tcpdump -i ipsec0 -s 0 -n icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
> 23:59:25.566796 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id 63869, seq 5, length 64
> 23:59:26.576196 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id 63869, seq 6, length 64
> 23:59:27.585537 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id 63869, seq 7, length 64
> 23:59:28.598500 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id 63869, seq 8, length 64
>
>
> but no reply is coming back. Next, I tried to add some NAT rules:
>
>
> root at DD-WRT:~# iptables -t nat -I POSTROUTING -s 10.10.0.0/24 -m policy --dir out --pol ipsec -j ACCEPT
> iptables v1.3.7: Couldn't find match `policy'
>
> but no luck.
>
> At this point I'm thinking it could be one of these four items:
>
>
> 1) Azure VPN Gateway is blocking ping from LOCAL to REMOTE. Having trouble figuring out how to pin point this via their logs or StrongSwan logs.
>
> 2) StrongSwan is misconfigured so pings towards one of the REMOTE VLAN's is never sent over the StrongSwan VPN Gateway at all. Leaning towards this since packets aren't even making it into ipsec0 interface to begin with unless I ping from REMOTE to LOCAL. At that point it appears they terminate at the ipsec0 interface and go no further, hence suspecting misconfiguration. But can't prove it yet.
>
> 3) I need NAT rules such as the one above.
>
> 4) I'm missing kernel modules on DD-WRT. Or a module isn't loaded, when it should be.
>
>
> --
> Thx,
> TK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200619/2b5afd50/attachment-0001.html>
More information about the Users
mailing list