TCP ACK create separate NAT state on IPsec enc0 for LAN attached hosts

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

TCP ACK create separate NAT state on IPsec enc0 for LAN attached hosts

Denis Lapshin-2

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

Reply | Threaded
Open this post in threaded view
|

Re: TCP ACK create separate NAT state on IPsec enc0 for LAN attached hosts

Denis Lapshin-2
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
>