Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 8 Dec 2016 16:49:32 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-ipfw@freebsd.org
Subject:   IPFW problem with passing IPSEC through in-kernel NAT
Message-ID:  <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net>
next in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
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!

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
_0[0C)0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z10	UUS10UFlorida10U
Cuda Systems LLC10UKarl Denninger (OCSP)0"0
	*H
0
X@vkY
Tq/vE]5#֯MX\8LJ/V?5Da+
sJc*/r{ȼnS+w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-<	?HN5y
5}F|ef゘"Vلio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬϜ/,$+;4y'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YPEC)TY>~/˘N[vyiDKˉ,^" ?$T8v&K%z8C @?K{9f`+@,|Mbia007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U-h\Ff Y0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
Owbabɺx&Uk[(Oj!%pMQ0I!#QH}.>~2&D}<wm_>V6v]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր_up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q-(cAeGX)f}-˥6cv~Kg8m~v;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p#}DZ9;V9#>Sw"[UP7100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	`HeM0	*H
	1	*H
0	*H
	1
161208224932Z0O	*H
	1B@
EW^r&+ہ,9&Aި<oC:9$@V]KdHy0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	*H
X51_l.PY,R9tܖ8.BFJynJGr6M80	YC_\T{+9
^ؓqhXhOyn_'=ՖMl@.UdǣٸyO9c?Rn4SjPLF-kuZBcDv4dw4x^uaǢ_:yZ{u熚KZs)quيM:
#?Dj<{ vW8̗z=<vPdm×2>uS>s]^>ˆӋc"CoERAHaW!sc5j%(z[m\s"'j68z3\lJ/d?9<cQCB_N
8>xKwvF7$Nv
/-7q)+([Iq[

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?099203a1-f601-bb79-548d-27c62fcbf556>