Hi all! I've been trying to figure out how to direct traffic into internal hosts through IPsec (IKEv2, enc0). My client is an Android phone, using strongSwan, connecting to an OpenBSD 6.5 VPN concentrator. The VPN server has two IP addresses on enc0, 172.16.0.1/24 and 172.16.0.21/24. I wanted to use the latter as a 1:1 map to an internal IP address, like 192.168.0.21. Basically everything I would send to 172.16.0.21 to any port from the client/phone, I would want to direct that to 192.168.0.21 to the same dst port.
[client/phone] (172.16.0.42/24) <-> (172.16.0.1/24, 172.16.0.21/24) [OpenBSD
VPN server] (192.168.0.1/16) <-> (192.168.0.21/16) [internal host]
I wanted to test this with icmp first, and build up from there:
# ifconfig enc0
enc0: flags=41<UP,RUNNING>
index 5 priority 0 llprio 3
groups: enc
status: active
inet 172.16.0.1 netmask 0xffffff00
inet 172.16.0.21 netmask 0xffffff00
/etc/pf.conf:
==========8<==========
match all scrub (no-df random-id) # I tried to remove this, but didn't seem
to make any difference
[...]
pass in on egress proto udp to port {isakmp, ipsec-nat-t} label IKE
pass in on egress proto esp label IKE
match in on enc inet proto icmp from (enc:network) to 172.16.0.21 \
rdr-to 192.168.0.21 \
tag IPSEC_RDR_PASS
pass on enc tagged IPSEC_RDR_PASS
==========8<==========
>From the client/phone I can ping 172.16.0.1, naturally, but when it comes to
>172.16.0.21, on the enc0 interface there's this traffic, which seems fine to
>me:
VPN server# tcpdump -nttti enc0
tcpdump: listening on enc0, link-type ENC
Jul 19 22:27:11.842500 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 >
172.16.0.21: icmp: echo request (DF) (encap)
Jul 19 22:27:12.861873 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 >
172.16.0.21: icmp: echo request (DF) (encap)
Jul 19 22:27:13.921964 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 >
172.16.0.21: icmp: echo request (DF) (encap)
So it seems the redirect works, meanwhile on the 192.168.0.21 host:
internal host$ sudo tcpdump -ntttti eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2019-07-19 22:28:40.243669 IP 172.16.0.42 > 192.168.0.21: ICMP echo request, id
18, seq 1021, length 64
2019-07-19 22:28:40.243705 IP 192.168.0.21 > 172.16.0.42: ICMP echo reply, id
18, seq 1021, length 64
2019-07-19 22:28:40.243974 IP 192.168.0.1 > 192.168.0.21: ICMP 172.16.0.42
unreachable - need to frag, length 36
2019-07-19 22:28:41.283963 IP 172.16.0.42 > 192.168.0.21: ICMP echo request, id
18, seq 1022, length 64
2019-07-19 22:28:41.283999 IP 192.168.0.21 > 172.16.0.42: ICMP echo reply, id
18, seq 1022, length 64
2019-07-19 22:28:41.284335 IP 192.168.0.1 > 192.168.0.21: ICMP 172.16.0.42
unreachable - need to frag, length 36
So icmp gets into the internal network, it just couldn't find its way back.
>From 192.168.0.21 I can ping 172.16.0.{1, 21} fine (both IP addresses on enc0
>on the VPN server), but when it comes to .42 (the above IPsec client, the
>phone), if I try to ping it, I get the same error:
internal host$ ping 172.16.0.42
PING 172.16.0.42 (172.16.0.42) 56(84) bytes of data.
>From 192.168.0.1 icmp_seq=1 Frag needed and DF set (mtu = 0)
>From 192.168.0.1 icmp_seq=2 Frag needed and DF set (mtu = 0)
Is there something fundamentally wrong with this? How would this work ideally?
I even tried to setup a NAT rule when coming in from the VPN to the LAN, so
everything from 172.16.0/24 would be NATed to 192.168.0.1, the VPN server's
internal IP:
match out on enc from (enc:network) to (em0:network) \
nat-to 192.168.0.1
Now this didn't do anything, at least from the above tcpdumps' point of view :-\
Thanks for any hints!
Dani
publickey - leva@ecentrum.hu - 0x66E1F716.asc
Description: application/pgp-keys
