Date: Thu, 8 Dec 2016 22:11:38 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-ipfw@freebsd.org Subject: Re: IPFW problem with passing IPSEC through in-kernel NAT Message-ID: <005b34c8-2217-fa06-5584-6999022481a3@denninger.net> In-Reply-To: <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net> References: <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms060600010006020500070005
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 cellphone=
s
> 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 throug=
h
> 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 e=
nd:
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=3D112
(p: #1 protoid=3Disakmp transform=3D12 len=3D112
(t: #1 type=3Dencr id=3D1des )
(t: #2 type=3Dencr id=3D3des )
(t: #3 type=3Dencr id=3Daes (type=3Dkeylen value=3D0080))
(t: #4 type=3Dencr id=3Daes (type=3Dkeylen value=3D0100))
(t: #5 type=3Dinteg id=3Dhmac-md5 )
(t: #6 type=3Dinteg id=3Dhmac-sha )
(t: #7 type=3Dinteg id=3Daes-xcbc )
(t: #8 type=3Dprf id=3Dhmac-sha )
(t: #9 type=3Dprf id=3Daes128_xcbc )
(t: #10 type=3Ddh id=3Dmodp1024 )
(t: #11 type=3Ddh id=3Dmodp1536 )
(t: #12 type=3Ddh id=3Dmodp2048 )))
(v2ke: len=3D128 group=3Dmodp1024)
(nonce: len=3D20 nonce=3D(7ab63afdd30a89278e3c0fac813dc44e05becba2) )=
(n: prot_id=3D#0 type=3D16388(nat_detection_source_ip))
(n: prot_id=3D#0 type=3D16389(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=3D#0 type=3D17(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=3D112
(p: #1 protoid=3Disakmp transform=3D12 len=3D112
(t: #1 type=3Dencr id=3D1des )
(t: #2 type=3Dencr id=3D3des )
(t: #3 type=3Dencr id=3Daes (type=3Dkeylen value=3D0080))
(t: #4 type=3Dencr id=3Daes (type=3Dkeylen value=3D0100))
(t: #5 type=3Dinteg id=3Dhmac-md5 )
(t: #6 type=3Dinteg id=3Dhmac-sha )
(t: #7 type=3Dinteg id=3Daes-xcbc )
(t: #8 type=3Dprf id=3Dhmac-sha )
(t: #9 type=3Dprf id=3Daes128_xcbc )
(t: #10 type=3Ddh id=3Dmodp1024 )
(t: #11 type=3Ddh id=3Dmodp1536 )
(t: #12 type=3Ddh id=3Dmodp2048 )))
(v2ke: len=3D128 group=3Dmodp1024)
(nonce: len=3D20 nonce=3D(ec204213e7501c0988dfb8ae84421b1224d10f7f) )=
(n: prot_id=3D#0 type=3D16388(nat_detection_source_ip))
(n: prot_id=3D#0 type=3D16389(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.
--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------ms060600010006020500070005
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl
bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND
dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD
ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg
XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp
3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f
IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO
aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ
Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5
vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq
yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/
o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l
eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI
KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw
CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB
DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX
RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw
FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6
eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf
G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO
sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb
An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+
JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ
3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat
HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0
FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG
1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT
n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD
MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5
c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDkwNDExMzhaME8GCSqGSIb3DQEJBDFCBECc
UWmjgIYKZYzPU6p7kJBUN+9Ap+imMq9tHtWWRjH5zEeeP0jXCPdvOr/QLvH2MOyzMF3CAPo+
9WkTtmXZ3FAaMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAakN3GzE/
FUE3CBJ6dUbiGrLVWzqLm+Kltvzbsb7iRXiWhm7mtYrRSHzAjf02gPmY0Zf4WgAbIY+ysNEi
6keBtT1a2sBKHw9UF0kH8pCEoj6OuVE/3k8AWn205sE45tGLdFBIlrjjPV+im8lM/zMNYOfu
e9dE9KSk+5jFs07Mk3JFK5gybPoJGJl0+MFNwlk6frXMmuYvANFaj6wa/dATpB6Ey83oub10
XvX2eUvQY3wvbINQXWS/K3cDDfEJPVVoXV3xlMnRsdLFioRGqtcmuwu0D9ykZA6kAiq1mQNB
+CErlSamydWxj7q4XN1WT+IoSCCc9z8yyU1JhSggghvnE2HcP4KvuY9W/9G73X8C2qlJOJtJ
J0LwXjisijlOOat9a3WOKSTM0PLOmZiFfdvnRS0+R5XBC6vuiB+cixqUq3oOzI+ngMVfG0sh
CTFUH1Jt0v5A7Wp4bLY8QY3mH2IYlutODORVId6T02fcYUe7n/1EdkgyiFC03h+kQnyM+lAY
dFNIUzlt4+kHsBGdXNwxMOjvfIrb1hmFb8bdziwrP4/coSEj/YvOxEqP348rmsyW00hKxBre
w4hfkjHXJCk65WErxgr2ZfSp//PQf/WmkxdvAkmg5PZdQO6NNYR9kY423OYBI1WtDbpbzVG8
xA8e7KsbeG0wOQylrp7H0Hl27cEAAAAAAAA=
--------------ms060600010006020500070005--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005b34c8-2217-fa06-5584-6999022481a3>