IPFW problem with passing IPSEC through in-kernel NAT
Karl Denninger
karl at denninger.net
Fri Dec 9 04:11:47 UTC 2016
On 12/8/2016 16:49, Karl Denninger wrote:
> Hi folks;
>
> I have a fairly complex configuration here with IPSEC on a gateway
> machine, which is working fine. However, I also wish to pass through
> *client* IPSEC setup requests (which happen to be coming from cellphones
> that want to use WiFi calling) as well, and have run into a problem.
>
> T-Mobile's WiFi calling appears to set up an IPSEC tunnel back to the
> company when turned on. The issue I'm running into is that while this
> is *supposed* to work with a device behind a NAT router (and does in
> other locations around the area) my FreeBSD gateway (which also happens
> to run the IPSEC gateway) always appears to pass the *internal* address
> (!) for the phone outbound, and refuses to put the setup packets through
> NAT. If I shut down IPSEC on the gateway machine and remove all of its
> ipfw rules it still doesn't work; I get authentication errors returned
> (when looking at the data stream with tcpdump to and from the phone
> device) which implies that the packets sent to the host are being
> tampered with -- along with some untranslated transmissions as well.
>
> Does anyone have a sample configuration that works with T-Mobile's WiFi
> calling and FreeBSD's internal kernel NAT solution? That might be
> enough for me to figure out what's going on...
>
> FreeBSD 11.0-STABLE #13 r307318M: if the rev matters....
>
> Thanks in advance!
>
Some more information on this issue.... I suspect that something is
getting mangled somewhere in the IP stack, perhaps related to hardware
checksumming or similar -- or in the ipfw code.
If I do not block (explicitly) UDP packets from the phone's IP from
getting out that have not been translated, I get some IPSEC (but no
other) packets that get through the NAT level (!). If I block those
then the ones that DO go out facially might be ok and might not; here's
an example of one that DOES translate and the reply back from the other end:
21:40:59.400170 IP (tos 0x0, ttl 253, id 5901, offset 0, flags [DF],
proto UDP (17), length 388)
denninger.net.56595 > m043536d0.tmodns.net.isakmp: [udp sum ok]
isakmp 2.0 msgid 00000000 cookie f4db8a5ed1c6fb54->0000000000000000:
parent_sa ikev2_init[I]:
(sa: len=112
(p: #1 protoid=isakmp transform=12 len=112
(t: #1 type=encr id=1des )
(t: #2 type=encr id=3des )
(t: #3 type=encr id=aes (type=keylen value=0080))
(t: #4 type=encr id=aes (type=keylen value=0100))
(t: #5 type=integ id=hmac-md5 )
(t: #6 type=integ id=hmac-sha )
(t: #7 type=integ id=aes-xcbc )
(t: #8 type=prf id=hmac-sha )
(t: #9 type=prf id=aes128_xcbc )
(t: #10 type=dh id=modp1024 )
(t: #11 type=dh id=modp1536 )
(t: #12 type=dh id=modp2048 )))
(v2ke: len=128 group=modp1024)
(nonce: len=20 nonce=(7ab63afdd30a89278e3c0fac813dc44e05becba2) )
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
21:40:59.455522 IP (tos 0xc0, ttl 54, id 17839, offset 0, flags [DF],
proto UDP (17), length 66)
m043536d0.tmodns.net.isakmp > denninger.net.56595: [udp sum ok]
isakmp 2.0 msgid 00000000 cookie f4db8a5ed1c6fb54->f497c06d5e456d11:
parent_sa ikev2_init[R]:
(n: prot_id=#0 type=17(invalid_ke_payload))
The other end replies immediately with a complaint about the requested
keying..... it never gets any further.
If I *remove* the explicit block on the internal source address here:
${fwcmd} add 10999 deny log udp from 192.168.1.25 to any
Which I stuck directly above the two lines that allow these UDP targeted
packets to get out into the wild:
# Allow T-Mobile's WiFi Calling to work
${fwcmd} add 11000 pass udp from any to any 500 keep-state
${fwcmd} add 11010 pass udp from any to any 4500 keep-state
Then despite THIS line further up:
${fwcmd} add 2800 nat 100 udp from
192.168.1.0/24 any to not 192.168.0.0/16 isakmp out via ${nat_interface}
Which *should* force anything coming from that address and pointed at
any address for ipsec initiation through NAT I start seeing tcpdump
entries like this show up immediately on the interface:
21:47:44.748334 IP (tos 0x0, ttl 253, id 5999, offset 0, flags [DF],
proto UDP (17), length 388)
D15.Denninger.Net.34453 > m043536d0.tmodns.net.isakmp: [udp sum ok]
isakmp 2.0 msgid 00000000 cookie d5c4bc3dcbe650cc->0000000000000000:
parent_sa ikev2_init[I]:
(sa: len=112
(p: #1 protoid=isakmp transform=12 len=112
(t: #1 type=encr id=1des )
(t: #2 type=encr id=3des )
(t: #3 type=encr id=aes (type=keylen value=0080))
(t: #4 type=encr id=aes (type=keylen value=0100))
(t: #5 type=integ id=hmac-md5 )
(t: #6 type=integ id=hmac-sha )
(t: #7 type=integ id=aes-xcbc )
(t: #8 type=prf id=hmac-sha )
(t: #9 type=prf id=aes128_xcbc )
(t: #10 type=dh id=modp1024 )
(t: #11 type=dh id=modp1536 )
(t: #12 type=dh id=modp2048 )))
(v2ke: len=128 group=modp1024)
(nonce: len=20 nonce=(ec204213e7501c0988dfb8ae84421b1224d10f7f) )
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
That shouldn't be possible since it should not be possible for an
untranslated internal IP address to get through the NAT part of the ipfw
table with an internal source and 500 destination port, and in fact some
of the packets that go into there DO get translated -- but apparently
incorrectly.
All other packet traffic works as expected both from that device and
many others.
IPSEC_NAT_T is in the kernel.
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20161208/29d4da58/attachment.bin>
More information about the freebsd-ipfw
mailing list