IPsec (Strongswan) testing... help needed urgently
Philip Prindeville
philipp_subx at redfish-solutions.com
Fri Nov 27 13:14:59 EST 2020
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 at 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 at 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 at OpenWrt2:~#
root at 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 at OpenWrt2:~#
root at 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 at 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
More information about the openwrt-devel
mailing list