Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 4 May 2017 11:22:05 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-ipfw@freebsd.org
Subject:   Question that has dogged me for a while.
Message-ID:  <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net>
index | next in thread | raw e-mail 

[-- Attachment #1 --]
Consider the following network configuration.


Internet ------- Gateway/Firewall ---------- Inside network (including a
web host)
            70.16.10.1/28     192.168.0.0/24  

The address of the outside is FICTIONAL, by the way.

For policy reasons I do NOT want the gateway machine to actually have
the host on it.  There may be a number of things running on there but
for the instant moment let's assume a standard pedestrian web host on
port 80.

I have DNS pointing at "webhost.domain" @ 70.16.10.1.

I have NAT on the gateway (NAT internal to the kernel), and a "hole
punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as
pat of the nat configuration statement.

This works fine for anyone on the outside.  HOWEVER, anyone on the
INTERNAL network cannot see the host.

My NAT configuration looks like this:

#
# Now divert all inbound packets that should go through NAT. Since this
is NAT
# it can only match a packet that previously was NATted on the way out.
#
        ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
#
# Check stateful rules; we want to go there directly if there is a match
#
        ${fwcmd} add 7000 check-state
#
# Now pick up all *outbound* packets that originated from an inside address
# and put them through NAT.  We then have
# a packet with a local source address and we can allow it to be sent.
# Therefore, if the packet is outbound let it pass and be done with it.
#
        ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif}
>>    ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip}
        ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit
${oif}
        ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif}

Without the ">>" line I get nothing; the packets get to the gateway and
disappear.

With the ">>" line I DO get the packets re-emitted on the internal
interface HOWEVER there is no translation to the internal interface IP
on the gateway box.  So what I see on the internal box is this:

11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
[S], seq 292171178, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags
[S.], seq 3088872007, ack 292171179, win 65535, options [mss
1460,nop,wscale 6,sackOK,eol], length 0

Which won't work because the internal box got and sent this:

11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S],
seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
length 0
11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S],
seq 2666765817, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
[S], seq 292171178, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags
[S], seq 2666765817, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0

But since the gateway emitted the packet back on the wire *without*
remapping the source address (to itself) it doesn't match on the client
box 'cause there's no way back for it.

There has to be a solution to this somewhere and I'm obviously missing
it..... :)

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

[-- Attachment #2 --]
0	*H
010
	`He0	*H
\0X0@=0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
161218194535Z
211217194535Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
͍fd`1ie6";fSz`5¹/?{=Ӵowjħ_fnӴMG\ҢҖ4ib}>@mJo&mM;
Q9U cj]p퐆W.2E=
^¢tzĄ'5i7_`~#dY
`]R]N%R}EXzqV@[oN	T>5AwYˡA"\v&YG]+($p:M,T?=mJkMљg*ym
L!J[./d׷?W^LysD'1
+V'~{-SSX=q-f=%&V<m4BeSet|
l2m 6iO{wv
+aHXˈ5=~é*C!?uJr3tb'3`Oe)üLxt&3N526llU
.|Cp[l?007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U/Zi
0GhG0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
b%X%gwq	
ɁэrK[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7jGj9铚~3f2AʺN	k~@vz^j(>ͺyh2y{/9}4.45#S|<fW!.,Bss*Q+h=}l@	"q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1򹿈nZ5TuPvW|#G+	DZpI7S'n0 haGa@vZ	e|]Cu+))vRyY100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	`HeM0	*H
	1	*H
0	*H
	1
170504162209Z0O	*H
	1B@#nTW{86Ң@	,e/eHQ?xh6ɬy&?/c]#i|R~`A0l	*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
rؕ~O${A
dw)$ل>Z7m%ʆwd5d Gμ	N6w5|*eAN(|Ln@]<GF4['Rb&)[XL&n)&^3M
+"Bj &ݒ5j付4Ot<+a[i)%$JpCO7Ʌ
aj/b> G>:uvWܫ)^d`$
''-SVKbg\y+\r,v$ɠRv&kQl)PrQkzGKj*)0=N.WL_#!k}5N_H%c8GO}c;:wx̭hz4v4_b)p{Ft*]c5Ǧ@Д+kuJwY>rf9mwD
help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26ccc7eb-bed3-680c-2c86-2a83684299fb>