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
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
