Hi, I’m working on a PR to add X.509 certificates to Strongswan for authentication and that all seems to be working fine:
https://github.com/openwrt/packages/pull/14028 But I can’t figure out why my traffic isn’t being passed, even though the tunnel comes up: root@OpenWrt2:~# ip xfrm state src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel replay-window 0 flag af-unspec aead rfc4106(gcm(aes)) ... 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 src 45.33.216.244 dst 174.27.7.72 proto esp spi 0xc6a9b1c6 reqid 1 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) ... 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 root@OpenWrt2:~# ip xfrm policy src 192.168.3.0/24 dst 192.168.2.0/24 dir out priority 375423 tmpl src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel src 192.168.2.0/24 dst 192.168.3.0/24 dir fwd priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.2.0/24 dst 192.168.3.0/24 dir in priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.3.0/24 dst 192.168.1.0/24 dir out priority 375423 tmpl src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel src 192.168.1.0/24 dst 192.168.3.0/24 dir fwd priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.1.0/24 dst 192.168.3.0/24 dir in priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 root@OpenWrt2:~# root@OpenWrt2:~# ip -4 addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 9: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 174.27.7.72/19 brd 174.27.31.255 scope global eth3 valid_lft forever preferred_lft forever 17: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 192.168.3.1/24 brd 192.168.3.255 scope global br-lan valid_lft forever preferred_lft forever root@OpenWrt2:~# root@OpenWrt2:~# ip -4 route show default via 174.27.0.1 dev eth3 proto static src 174.27.7.72 174.27.0.0/19 dev eth3 proto kernel scope link src 174.27.7.72 192.168.3.0/24 dev br-lan proto kernel scope link src 192.168.3.1 root@OpenWrt2:~# But if I do a “ping 192.168.1.252” then I see unencapsulated packets leaking out my “wan” (eth3) interface with my public (masqueraded) address: 10:33:06.093236 IP (tos 0x0, ttl 64, id 59993, offset 0, flags [DF], proto ICMP (1), length 84) 174.27.7.72 > 192.168.1.252: ICMP echo request, id 9506, seq 5, length 64 And doing “ping -I 192.168.3.1 192.168.1.252” doesn’t seem to make any difference. What would stop the XFRM’s from matching the traffic and causing it to be encapsulated? Only thing I can think of is that NATting is happening before the XFRM can happen, but that doesn’t make sense because the masquerading happens very late: -A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE The relevant parts (from what I can tell) of my /etc/config/firewall look like: config defaults option syn_flood 1 option input ACCEPT option output ACCEPT option forward REJECT # Uncomment this line to disable ipv6 rules option disable_ipv6 1 option tcp_ecn 1 config zone option name vpn option input ACCEPT option output ACCEPT option forward ACCEPT option subnet '192.168.1.0/24' option extra_src '-m policy --dir in --pol ipsec --proto esp' option extra_dest '-m policy --dir out --pol ipsec --proto esp' option mtu_fix 1 ... config zone option name wan list network 'wan' list network 'wan6' option input DROP option output ACCEPT option forward DROP option masq 1 option mtu_fix 0 option log 1 config forwarding option src lan option dest wan ... config rule option name Allow-IPSec-ESP option src wan option dest * option proto esp option family ipv4 option target ACCEPT config rule option name Allow-ISAKMP option src wan option src_port 500 option dest * option dest_port 500 option proto udp option family ipv4 option target ACCEPT config rule option name Allow-ISAKMP-NAT option src wan option src_port 4500 option dest * option dest_port 4500 option proto udp option family ipv4 option target ACCEPT ... And my /etc/config/ipsec looks like: config ipsec option zone 'vpn' option listen 'wan' list listen 'wan' option debug '1' config remote 'home' option enabled '1' option gateway '45.33.216.244' option local_identifier 'C=US, O=Redfish-Solutions, CN=apart' option remote_identifier 'C=US, O=Redfish-Solutions, CN=home' option authentication_method 'pubkey' list crypto_proposal 'strong_ike_proposal' option force_crypto_proposal 1 list tunnel 'tun_home' config crypto_proposal 'strong_ike_proposal' option encryption_algorithm 'aes256gcm128' option hash_algorithm 'sha512' option dh_group 'modp2048' config tunnel 'tun_home' option mode 'start' option reauth 0 option local_leftip '%defaultroute' option local_subnet '192.168.3.0/24' option remote_subnet '192.168.1.0/24,192.168.2.0/24' # option remote_subnet '192.168.1.0/24' list crypto_proposal 'strong_esp_proposal' option force_crypto_proposal 1 option local_cert 'apart.crt' option local_key apart.key option fragmentation 1 option keyingtries 0 option ikelifetime '1h' option lifetime '8h' option closeaction 'restart' option keyingtries '%forever' option mobike 0 config crypto_proposal 'strong_esp_proposal' option encryption_algorithm 'aes256gcm128' option hash_algorithm ’sha512' And yes, I have the following files: /etc/ipsec.d/certs/apart.crt /etc/ipsec.d/private/apart.key /etc/ipsec.d/secrets/home /etc/ipsec.d/cacerts/redfish-solutions.crt (CA) Eventually it might be nice to have the certs & keys imported from UCI itself, but… that can be done in the future. Maybe via a keychain and referencing things in that keychain. Anyone have some cycles to look at this with me? Thanks, -Philip _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
