It seems the issue related to tread "Packets originating from IKED tunnel have a bad ip chksum" https://marc.info/?l=openbsd-bugs&m=157859648503190&w=2
On 2/13/2020 4:15 PM, Denis wrote: > > I have working IKEv2 VPN between both OpenBSD 6.6 responder (server) and > 6.6 initiator (client) which connects to responder from behind ISP NAT. > My configuration is very close to FAQ with OpenBSD initiator connection > behind ISP NAT to a responder described in: > https://www.openbsd.org/faq/faq17.html#clientikev2 > > When VPN is disconnected on initiator's machine and all external > connections go trough egress in clear, NAT on egress works as should be > for initiator itself and LAN hosts connected to the initiator's LAN > using pf.conf second NAT rule for 'tagged WEB' packets: > > ... > match out log on enc0 inet all nat-to 10.0.5.2 tagged WEB > match out log on egress from 192.168.2.0/24 to any nat-to (egress) > tagged WEB > ... > > Once VPN is connected, NAT works for initiator itself only, and no > traffic translation for initiator's LAN connected hosts on enc0 NAT > using first PF rule above. tcpdump shows that NAT creates second > separate state for ACKs to each TCP outgoing connection, so LAN host > never receive ACKs for its initial TCP request. > > As shown below, NAT creates separate state for ACK on enc0 from VMM host > 192.168.2.4 placed in initiator's virtual LAN 192.168.2.0/24. The same > is for any different physical LAN connected hosts to initiator's machine. > > $ telnet 172.217.21.142 80 (from LAN VMM host 192.168.2.4) > > tcpdump -en -i pflog0 > 13.29.33.694116 rule 4/(match) match out on enc0: 10.0.5.2.64401 > > 172.217.21.142.80 S 3601041753:3601041753(0) win 64240 <mss > 1440,sackOK,timestamp 295653344 0,nop,wscale 7> [tos 0x10] > 13.29.33.694116 rule 135/(match) match out on enc0: 10.0.5.2.64401 > > 172.217.21.142.80 S 3601041753:3601041753(0) win 64240 <mss > 1440,sackOK,timestamp 295653344 0,nop,wscale 7> [tos 0x10] > 13.29.34.316393 rule 4/(match) match out on enc0: 10.0.5.2.50426 > > 192.168.2.4.59062 S 880722202:880722202(0) ack 3601041754 win 60192 <mss > 1380,sackOK,timestamp 709481652 2965653344,nop,wscale 8> > 13.29.34.625518 rule 4/(match) match out on enc0: 10.0.5.2.54501 > > 192.168.2.4.59062 S 880722202:880722202(0) ack 3601041754 win 60192 <mss > 1380,sackOK,timestamp 709481953 2965653344,nop,wscale 8> > > > Initiator's VMM LAN SA bypassed using ipsec.conf in all directions to > have VMM network unbound from IPsec SAs. So all requests from > 192.168.2.0/28 can be NATed to 10.0.5.2 virtual interface with ACK in > the same state. > > $ /etc/ipsec.conf > flow from 127.0.0.1/32 to 192.168.2.0/24 type bypass > flow from 192.168.2.0/24 to 127.0.0.1/32 type bypass > flow from 192.168.2.0/24 to 192.168.2.0/24 type bypass > > > responder /etc/iked.conf > ikev2 'responder' passive esp \ > from 0.0.0.0/0 to 10.0.5.0/24 \ > local 9.8.7.6 peer any \ > srcid srv.vpn \ > > initiator /etc/iked.conf > ikev2 'initiator' active esp \ > from 10.0.5.2 (0.0.0.0/0) to 0.0.0.0/0 \ => to have traffic > appears for LAN hosts from 10.0.5.2 as in IPSEC.CONF(5) for NAT > configurations > peer 9.8.7.6 \ > srcid clnt.vpn \ > dstid srv.vpn > > /etc/pf.conf (initiator) > ... > match out log on enc0 inet all nat-to 10.0.5.2 tagged WEB > ... > > pass in log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state (if-bound) > pass out log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state > (if-bound) tagged WEB > > ... > pass in on 192.168.2.1 inet proto tcp from 192.168.2.0/24 to any port > {www, https} flags S/SA modulate state tag WEB > > I don't know exactly is it bug or misconfiguration, but it looks like > unexpected NAT behavior. > > Denis >
