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 <[email protected]> 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 <[email protected]> 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@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@DD-WRT:~# > > > > root@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@DD-WRT:~# > > > root@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@DD-WRT:~# > > > root@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@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@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@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@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@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@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@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@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.
