Re: Question that has dogged me for a while.

2017-05-08 Thread Freddie Cash 
On Fri, May 5, 2017 at 8:34 PM, Karl Denninger  wrote:

> Can you point me to the ruleset you posted?  Thanks in advance.
>
I can't remember all your network details, and don't have the e-mails
saved, so fill in the blanks below.  :)  And change the ports as needed.

​IIF=​
​EIF=

PUB_IP="me"
SRV_IP=
PRV_NET=​


​# NAT incoming traffic for port 8080 to server's private IP​
​ipfw nat 100 config same_ports ip $PUB_IP redirect_port tcp $PRV_IP:80
$PUB_IP:8080
​

# NAT outgoing traffic from private subnet to public IP
ipfw nat 200 config same_ports ip $PUB_IP
​

# Allow port 8080 traffic to server from private subnet (in)
ipfw add nat 100 tcp from $PRV_NET to $PUB_IP 8080 in  recv $IIF
ipfw add nat 200 tcp from $PRV_NET to $SRV_IP 80   out xmit $IIF

ipfw add nat 200 tcp from $SRV_IP 80   to $PUB_IP  in  recv $IIF
ipfw add nat 100 tcp from $PUB_IP 8080​ to $PRV_NET out xmit $IIF


# Allow port 8080 traffic from Internet to server (in)
ipfw add nat 200 tcp from anyto $PUB_IP 8080 in  recv $EIF
ipfw add allow   tcp from anyto $SRV_IP 80   out xmit $IIF

ipfw add allow   tcp from $SRV_IP 80 to any  in  recv $IIF
ipfw add nat 200 tcp from $SRV_IP 80 to any  out xmit $EIF


​# Allow clients access to Internet (out)
ipfw add allow   tcp from $PRV_NET to any  in  recv $IIF
ipfw add nat 100 tcp from $PUB_IP  to any  out recv $EIF

ipfw add nat 100 tcp from any  to $PUB_IP  in  recv $EIF
ipfw add allow   tcp from any  to $PRV_NET out xmit $IIF
​

​# Block the rest
ipfw add deny log ip from any to any in recv $EIF
ipfw add deny log ip from any to any in recv $IIF
​

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

2017-05-05 Thread Julian Elischer 

On 6/5/17 8:14 am, Karl Denninger wrote:

On 5/5/2017 19:08, Dr. Rolf Jansen wrote:

Am 05.05.2017 um 20:53 schrieb Karl Denninger :

On 5/5/2017 14:33, Julian Elischer wrote:

On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:

Resolving this with ipfw/NAT may easily become quite complicated, if
not impossible if you want to run a stateful nat'ting firewall, which
is usually the better choice.

IMHO a DNS based solution is much more effective.

On my gateway I have running the caching DNS resolver Unbound. Now
let's assume, the second level domain name in question is
example.com, and your web server would be accessed by
www.example.com, while other services, e.g. mail are served from
other sites on the internet.

I believe this is a much cleaner solution thanusing double NAT.
(see also my solution for if the server is also freebsd)
even though we have a nice set of new IPFW capabilities that can do
this, I still think double nat is an over complication of the system.


Well, the DNS answer is one that works IF you control the zone in
question every time. ...

I do not understand "control the zone ... every time".

I set up my transparent zones 5 years ago and never touched it again, and I don't see any 
"illegal" packets on my network caused by this either.

I understand that you actually didn't grasp the transparent zone technic.

Happy double nat'ting :-D

On the contrary I do understand it (and how to do it), along with how to
throw "off-network" packets at the other host.  Both ways work (unbound
is arguably simpler than BIND, but it'll work in both cases) but the
point is that you then must keep two things in sync rather than do one
thing in one place.

If double-nat'ing isn't supposed to work with in-kernel ipfw nat because
the first nat never leaves an interface then it is what it is, but if it
IS supposed to work  then is not this misfeature a roach on the floor
that perhaps ought to get squashed?
I think the problem MAY be that the return packets from the internal 
(reverse) nat are taking the same path as the original packets. 
(confusing libalias)
You are saying that the packets coming from 192.168.x.x are CLIENT 
packets and then you expect the packets from the server to be treated 
the differently, even tough they are the same. I think the NAT doesn't 
know which way to apply them as.






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

2017-05-05 Thread Julian Elischer 

On 6/5/17 7:53 am, Karl Denninger wrote:

On 5/5/2017 14:33, Julian Elischer wrote:

On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:

Resolving this with ipfw/NAT may easily become quite complicated, if
not impossible if you want to run a stateful nat'ting firewall, which
is usually the better choice.

IMHO a DNS based solution is much more effective.

On my gateway I have running the caching DNS resolver Unbound. Now
let's assume, the second level domain name in question is
example.com, and your web server would be accessed by
www.example.com, while other services, e.g. mail are served from
other sites on the internet.

I believe this is a much cleaner solution thanusing double NAT.
(see also my solution for if the server is also freebsd)
even though we have a nice set of new IPFW capabilities that can do
this, I still think double nat is an over complication of the system.


Well, the DNS answer is one that works IF you control the zone in
question every time.  I'm loathe to stick "illegal" (e.g. bad IP number)
packets on a network in any event, so while yeah, that'll work I'd
rather not.


Interestingly the "bad" IP packets are no different than the packets 
you are  seeing on the network anyhow (with nat).

You just deliver them to a different place.
Effectively you are turning on the transparent proxy support in the 
kernel and making the gateway a transparent proxy for your clients. 
(but only for your own server)


for example  if your client is 192.168.0.2
and your server is 192.168.0.3 and your external address is 8.8.8.9,

Then what you are asking for is a way that your client can make a 
session where the remote address is 8.8.8.9 and the local address is 
192.168.0.2.
You are going to generate these packets no matter what you do because 
they are what you asked to do even if you are NATing.


The packets when bounced to the server STILL look like 
src=192.169.0.2, dest=8.8.8.9 and the server(FreeBSD or Linux with TP 
support only) will consume them as such.
The server will produce a packet that looks like src=8.8.8.9, 
dest=192.168.0.2.These packets look exactly like the packets that 
would be returning from the NAT to the client had you used nat.


so, overall, you are not introducing any packets onto your network 
that wouldn't have been there anyhow.
They look exactly like the traffic would look between the NAT and the 
client.
The difference is that it is way more efficient, because the return 
packets take no processing at all.


The advantage of setting up a DNS (mostly) forwarding proxy is that 
what is happening is absolutely visible on the wire.

Nothing is pretending to be anything it is not.

The nat option on the other hand.
 (don't get me wrong, I am sure it would work given enough work) is 
that it just has more moving parts and will make it more complicated 
to get your firewall correct in other cases.

I like ipfw and it's nat, it's just more complicated in some cases.


The "set up a fake forward" zone thing works too, but it shouldn't have to.

This /should /work on a generalized basis but doesn't (ue1 is on the
public address 70.169.168.7, ue0 on private address 192.168.10.200, the
host being "twisted to/hole punched" is on 192.168.10.100:

# Set up the NAT configuration
#
 ${fwcmd} nat 100 config if ue1 log same_ports reset
redirect_port tcp 192.168.10.100:2552 2552
 ${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset



shouldn't one of these be declared to be a reverse nat?




060000   0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200
06010 1521  726601 nat 100 ip4 from any to me recv ue1
070000   0 check-state :default

080006 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7
080010   0 count log ip4 from 192.168.10.200 to any dst-port 2552
08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1
080090   0 deny log ip4 from 192.168.0.0/16 to any xmit ue1

A "telnet 70.169.168.7 2552" from outside works perfectly well.  But the
second NAT should cause a "telnet 70.169.168.7 2552" from an
internet-network host to work also.  It doesn't.

8000 gets the packet (a telnet attempt from inside to port 2552) and
allegedly is supposed to NAT it.  It does not.  The following rule,
which is where execution should continue after it NATs it, should match
but no packet ever comes back into the stack -- nor does it show up on
the wire (tcpdump fails to show it.)  I have verbose logging on in
sysctl and none of the deny lines in the remainder of the ipfw config
file trap it either.

The *other* NAT instance on the same box (to translate other things on
the same network out to the Internet at large and perform the hole
punch) works perfectly well.

This looks like a bug in the code -- unless there's a requirement that a
packet in the kernel is marked to be enqueued for emission on an actual
physical interface before it will translate (e.g. a "forward" NAT has to
be associated with an "xmit "

Re: Question that has dogged me for a while.

2017-05-05 Thread Karl Denninger 
On 5/5/2017 21:56, Dr. Rolf Jansen wrote:
> Am 05.05.2017 um 21:14 schrieb Karl Denninger :
>> On 5/5/2017 19:08, Dr. Rolf Jansen wrote:
>>> Am 05.05.2017 um 20:53 schrieb Karl Denninger :
 On 5/5/2017 14:33, Julian Elischer wrote:
> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:
>> Resolving this with ipfw/NAT may easily become quite complicated, if
>> not impossible if you want to run a stateful nat'ting firewall, which
>> is usually the better choice.
>>
>> IMHO a DNS based solution is much more effective.
>>
>> On my gateway I have running the caching DNS resolver Unbound. Now
>> let's assume, the second level domain name in question is
>> example.com, and your web server would be accessed by
>> www.example.com, while other services, e.g. mail are served from
>> other sites on the internet.
> I believe this is a much cleaner solution thanusing double NAT.
> (see also my solution for if the server is also freebsd)
> even though we have a nice set of new IPFW capabilities that can do
> this, I still think double nat is an over complication of the system.
>
 Well, the DNS answer is one that works IF you control the zone in
 question every time. ...
>>> I do not understand "control the zone ... every time".
>>>
>>> I set up my transparent zones 5 years ago and never touched it again, and I 
>>> don't see any "illegal" packets on my network caused by this either.
>>>
>>> I understand that you actually didn't grasp the transparent zone technic.
>>>
>>> Happy double nat'ting :-D
>> On the contrary I do understand it (and how to do it), along with how to
>> throw "off-network" packets at the other host.  Both ways work (unbound
>> is arguably simpler than BIND, but it'll work in both cases) but the
>> point is that you then must keep two things in sync rather than do one
>> thing in one place.
> With BIND you cannot setup a selectively transparent zone. You are talking 
> about split DNS, and that's a different animal.
>
Well, sort of you can.

Look at "response-policy" in the options section of named.conf  It
does basically the same sort of thing that you can do with unbound; it's
been there for a while.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question that has dogged me for a while.

2017-05-05 Thread Dr. Rolf Jansen 
Am 05.05.2017 um 21:14 schrieb Karl Denninger :
> On 5/5/2017 19:08, Dr. Rolf Jansen wrote:
>> Am 05.05.2017 um 20:53 schrieb Karl Denninger :
>>> On 5/5/2017 14:33, Julian Elischer wrote:
 On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:
> Resolving this with ipfw/NAT may easily become quite complicated, if
> not impossible if you want to run a stateful nat'ting firewall, which
> is usually the better choice.
> 
> IMHO a DNS based solution is much more effective.
> 
> On my gateway I have running the caching DNS resolver Unbound. Now
> let's assume, the second level domain name in question is
> example.com, and your web server would be accessed by
> www.example.com, while other services, e.g. mail are served from
> other sites on the internet.
 I believe this is a much cleaner solution thanusing double NAT.
 (see also my solution for if the server is also freebsd)
 even though we have a nice set of new IPFW capabilities that can do
 this, I still think double nat is an over complication of the system.
 
>>> Well, the DNS answer is one that works IF you control the zone in
>>> question every time. ...
>> I do not understand "control the zone ... every time".
>> 
>> I set up my transparent zones 5 years ago and never touched it again, and I 
>> don't see any "illegal" packets on my network caused by this either.
>> 
>> I understand that you actually didn't grasp the transparent zone technic.
>> 
>> Happy double nat'ting :-D
> On the contrary I do understand it (and how to do it), along with how to
> throw "off-network" packets at the other host.  Both ways work (unbound
> is arguably simpler than BIND, but it'll work in both cases) but the
> point is that you then must keep two things in sync rather than do one
> thing in one place.

With BIND you cannot setup a selectively transparent zone. You are talking 
about split DNS, and that's a different animal.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

2017-05-05 Thread Karl Denninger 
On 5/5/2017 19:08, Dr. Rolf Jansen wrote:
> Am 05.05.2017 um 20:53 schrieb Karl Denninger :
>> On 5/5/2017 14:33, Julian Elischer wrote:
>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:
 Resolving this with ipfw/NAT may easily become quite complicated, if
 not impossible if you want to run a stateful nat'ting firewall, which
 is usually the better choice.

 IMHO a DNS based solution is much more effective.

 On my gateway I have running the caching DNS resolver Unbound. Now
 let's assume, the second level domain name in question is
 example.com, and your web server would be accessed by
 www.example.com, while other services, e.g. mail are served from
 other sites on the internet.
>>> I believe this is a much cleaner solution thanusing double NAT.
>>> (see also my solution for if the server is also freebsd)
>>> even though we have a nice set of new IPFW capabilities that can do
>>> this, I still think double nat is an over complication of the system.
>>>
>> Well, the DNS answer is one that works IF you control the zone in
>> question every time. ...
> I do not understand "control the zone ... every time".
>
> I set up my transparent zones 5 years ago and never touched it again, and I 
> don't see any "illegal" packets on my network caused by this either.
>
> I understand that you actually didn't grasp the transparent zone technic.
>
> Happy double nat'ting :-D
On the contrary I do understand it (and how to do it), along with how to
throw "off-network" packets at the other host.  Both ways work (unbound
is arguably simpler than BIND, but it'll work in both cases) but the
point is that you then must keep two things in sync rather than do one
thing in one place.

If double-nat'ing isn't supposed to work with in-kernel ipfw nat because
the first nat never leaves an interface then it is what it is, but if it
IS supposed to work  then is not this misfeature a roach on the floor
that perhaps ought to get squashed?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question that has dogged me for a while.

2017-05-05 Thread Dr. Rolf Jansen 
Am 05.05.2017 um 20:53 schrieb Karl Denninger :
> On 5/5/2017 14:33, Julian Elischer wrote:
>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:
>>> Resolving this with ipfw/NAT may easily become quite complicated, if
>>> not impossible if you want to run a stateful nat'ting firewall, which
>>> is usually the better choice.
>>> 
>>> IMHO a DNS based solution is much more effective.
>>> 
>>> On my gateway I have running the caching DNS resolver Unbound. Now
>>> let's assume, the second level domain name in question is
>>> example.com, and your web server would be accessed by
>>> www.example.com, while other services, e.g. mail are served from
>>> other sites on the internet.
>> 
>> I believe this is a much cleaner solution thanusing double NAT.
>> (see also my solution for if the server is also freebsd)
>> even though we have a nice set of new IPFW capabilities that can do
>> this, I still think double nat is an over complication of the system.
>> 
> Well, the DNS answer is one that works IF you control the zone in
> question every time. ...


I do not understand "control the zone ... every time".

I set up my transparent zones 5 years ago and never touched it again, and I 
don't see any "illegal" packets on my network caused by this either.

I understand that you actually didn't grasp the transparent zone technic.

Happy double nat'ting :-D

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

2017-05-05 Thread Karl Denninger 
On 5/5/2017 18:53, Karl Denninger wrote:
> A "telnet 70.169.168.7 2552" from outside works perfectly well.  But the
> second NAT should cause a "telnet 70.169.168.7 2552" from an
> internet-network host to work also.  It doesn't.
s/internet-network/inside-network/

:-)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question that has dogged me for a while.

2017-05-05 Thread Karl Denninger 

On 5/5/2017 14:33, Julian Elischer wrote:
> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote:
>> Resolving this with ipfw/NAT may easily become quite complicated, if
>> not impossible if you want to run a stateful nat'ting firewall, which
>> is usually the better choice.
>>
>> IMHO a DNS based solution is much more effective.
>>
>> On my gateway I have running the caching DNS resolver Unbound. Now
>> let's assume, the second level domain name in question is
>> example.com, and your web server would be accessed by
>> www.example.com, while other services, e.g. mail are served from
>> other sites on the internet.
>
> I believe this is a much cleaner solution thanusing double NAT.
> (see also my solution for if the server is also freebsd)
> even though we have a nice set of new IPFW capabilities that can do
> this, I still think double nat is an over complication of the system.
>
Well, the DNS answer is one that works IF you control the zone in
question every time.  I'm loathe to stick "illegal" (e.g. bad IP number)
packets on a network in any event, so while yeah, that'll work I'd
rather not.

The "set up a fake forward" zone thing works too, but it shouldn't have to.

This /should /work on a generalized basis but doesn't (ue1 is on the
public address 70.169.168.7, ue0 on private address 192.168.10.200, the
host being "twisted to/hole punched" is on 192.168.10.100:

# Set up the NAT configuration
#
${fwcmd} nat 100 config if ue1 log same_ports reset
redirect_port tcp 192.168.10.100:2552 2552
${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset


060000   0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200
06010 1521  726601 nat 100 ip4 from any to me recv ue1
070000   0 check-state :default

080006 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7
080010   0 count log ip4 from 192.168.10.200 to any dst-port 2552
08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1
080090   0 deny log ip4 from 192.168.0.0/16 to any xmit ue1

A "telnet 70.169.168.7 2552" from outside works perfectly well.  But the
second NAT should cause a "telnet 70.169.168.7 2552" from an
internet-network host to work also.  It doesn't.

8000 gets the packet (a telnet attempt from inside to port 2552) and
allegedly is supposed to NAT it.  It does not.  The following rule,
which is where execution should continue after it NATs it, should match
but no packet ever comes back into the stack -- nor does it show up on
the wire (tcpdump fails to show it.)  I have verbose logging on in
sysctl and none of the deny lines in the remainder of the ipfw config
file trap it either.

The *other* NAT instance on the same box (to translate other things on
the same network out to the Internet at large and perform the hole
punch) works perfectly well.

This looks like a bug in the code -- unless there's a requirement that a
packet in the kernel is marked to be enqueued for emission on an actual
physical interface before it will translate (e.g. a "forward" NAT has to
be associated with an "xmit " clause in order to work) in which case
it's impossible to make in-kernel NAT work for the "double twist" case
since the packet never leaves the box until it goes through the
hole-punch in the first NAT statement (which it *should* do in 8002,
right?)

Is that a bug (ought to PR it), a "feature" (e.g. design choice and thus
"working as intended") or do I (still) have it configured incorrectly?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question that has dogged me for a while.

2017-05-05 Thread Julian Elischer 

On 5/5/17 2:06 am, Karl Denninger wrote:

On 5/4/2017 12:12, Rodney W. Grimes wrote:

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:

What is the NAT command running at instance 100?
Does it have an -alias_address of inside IP of router?
Are you tryint to use the same Nat instance to do both
the global internet acess translation and this special
inside loop back translation?  If so that usually can
not be made to work.

Aha.  That's probably the problem -- I need a second instance.

Here's the entire salient section:


# Set up the NAT configuration; there are multiple entries that have to
be here
# because we redirect a bunch of ports around so we can see things from the
# outside -- specifically, webcams and the HomeDaemon server.
#
 ${fwcmd} nat 100 config ip ${oip} log same_ports reset
redirect_port tcp (whole bunch of stuff)

#
# Stop spoofing
#
 ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in
via ${oif}
 ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif}
 if [ -n "$inet6" ]; then
 ${fwcmd} add 2040 deny all from ${inet6} to any in via
${oif6}
 if [ -n "$onet6" ]; then
 ${fwcmd} add 2050 deny log all from ${onet6} to
any in \
 via ${iif6}
 fi
 fi

 ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}

#
# This table is a list of denied addresses that tried to attack us.  Updated
# by sshguard.  Anything coming inbound from the outside is blocked.  We
also
# block anything on the "screw you" lists (two)
#
 ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif}
 ${fwcmd} add 4010 deny all from any to ${foscam}
 ${fwcmd} add 4020 deny log all from ${china} to any via ${oif}
#
# Anything related to RFC1918 or the Manning range that comes in on
# the external interface (shouldn't happen) gets tossed immediately, EXCEPT
# for RFC1918 stuff coming in via IPSEC.  That we must pass or our IPSEC
# gateway will not work.
#
 ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec
recv ${oif}
 ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif}

#
# 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

Re: Question that has dogged me for a while.

2017-05-04 Thread Karl Denninger 


On 5/4/2017 14:44, Rodney W. Grimes wrote:
>> On 5/4/2017 13:47, Rodney W. Grimes wrote:
 On 5/4/2017 12:12, Rodney W. Grimes wrote:
>> Consider the following network configuration.
>>
>>
>> Internet --- Gateway/Firewall -- Inside network (including a
>> web host)
>> 70.16.10.1/28 192.168.0.0/24  
> ...
>
>>> It is almost impossible to remotly debug this type of stuff without a
>>> complete and full picture of all elements involved.
>>> As a minimum:
>>> ifconfig -a
>>> ipfw -a list
>>> sysctl net.inet.ip.fw.one_pass
>>> sysctl net.inet.ip.forwarding
>>>
>>> I know this can be made to work, I think even dd-wrt has it right
>>> And here is a good jumping off point from a very quick google:
>>> http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat-hairpinning/
>>>  
>> root@IPGw:/usr/local/etc # ifconfig -a
>> lo0: flags=8049 metric 0 mtu 16384
>> options=63
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>> inet 127.0.0.1 netmask 0xff00
>> groups: lo
>> nd6 options=21
>> ue0: flags=8843 metric 0 mtu 1500
>> options=80009
>> ether b8:27:eb:4e:88:64
>> inet 192.168.10.200 netmask 0xff00 broadcast 192.168.10.255
>> media: Ethernet autoselect (100baseTX )
>> status: active
>> nd6 options=29
>> ue1: flags=8843 metric 0 mtu 1500
>> options=8000b
>> ether 00:50:b6:5d:1d:9f
>> inet 70.169.168.7 netmask 0xff80 broadcast 70.169.168.127
>> media: Ethernet autoselect (100baseTX )
>> status: active
>> nd6 options=29
>> ue0.3: flags=8843 metric 0 mtu 1500
>> ether b8:27:eb:4e:88:64
>> inet 192.168.4.200 netmask 0xff00 broadcast 192.168.4.255
>> groups: vlan
>> vlan: 3 vlanpcp: 0 parent interface: ue0
>> media: Ethernet autoselect (100baseTX )
>> status: active
>> nd6 options=29
>>
>> root@IPGw:/usr/local/etc # ipfw -a list
>> 0010014 1042 allow ip from any to any via lo0
>> 00200 00 deny log ip from any to 127.0.0.0/8
>> 00300 00 deny log ip from 127.0.0.0/8 to any
>> 00400 00 deny log ip from any to ::1
>> 00500 00 deny log ip from ::1 to any
>> 02000 00 allow ip from 192.168.100.1 to any in via ue1
>> 02010 00 deny log ip from 192.168.0.0/16 to any not ipsec in
>> via ue1
>> 02020 00 deny log ip from 70.169.168.0/25 to any in via ue0
>> 03000 00 deny log ip from 70.169.168.0/25 to any recv ue0
>> 04000 00 deny log ip from table(22) to any recv ue1
>> 04010 00 deny ip from any to
>> 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83.89,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181.111.147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114.59,50.7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192.249.119,74.125.31.99
>> 04020 00 deny log ip from
>> 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 to
>> any via ue1
>> 05000 00 deny log ip from
>> 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1
>> 05010 00 deny log ip from
>> 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any
>> recv ue1
>> 06000  8726 10333291 nat 100 ip4 from any to me recv ue1
>> 07000 00 check-state :default
>> 0800021 1064 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7
> Where is the other half of nat 200?  This is from inside to outside IP,
> there needs to be a return nat occuring to de Nat the packets
> ipfw add 8000 nat 200 ip4 from 192.168.0.0/16 to 192.168.10.200,192.168.4.200
> It takes 2 rules to the same NAT to have working NAT usually, one for
> outbound packets, and one for inbound packets (relative to the NAT instance).
>
>
> Do we see atleast the packets this nats on the wire with tcpdump?
Nope!  That's the problem at this point.  I know there needs to be
another one; I'll add it but it shouldn't matter until after I see the
packets come out on the wire, right? (Added, no difference)
>> 08001  4834   264258 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1
>> 08009 00 deny log ip4 from 192.168.0.0/16 to any xmit ue1
>> 08010  4836   264410 allow ip4 from 70.169.168.0/25 to any xmit ue1
>> 08011 00 allow log ip from 192.168.10.200 to 192.168.0.0/16
>> dst-port 2552
>> 08020  5374   306553 allow ip

Re: Question that has dogged me for a while.

2017-05-04 Thread Karl Denninger 
On 5/4/2017 13:47, Rodney W. Grimes wrote:
>> On 5/4/2017 12:12, Rodney W. Grimes wrote:
 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:
>>> What is the NAT command running at instance 100?
>>> Does it have an -alias_address of inside IP of router?
>>> Are you tryint to use the same Nat instance to do both
>>> the global internet acess translation and this special
>>> inside loop back translation?  If so that usually can
>>> not be made to work.
>> Aha.  That's probably the problem -- I need a second instance.
>>
>> Here's the entire salient section:
>>
>>
>> # Set up the NAT configuration; there are multiple entries that have to
>> be here
>> # because we redirect a bunch of ports around so we can see things from the
>> # outside -- specifically, webcams and the HomeDaemon server.
>> #
>> ${fwcmd} nat 100 config ip ${oip} log same_ports reset
>> redirect_port tcp (whole bunch of stuff)
>>
>> #
>> # Stop spoofing
>> #
>> ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in
>> via ${oif}
>> ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif}
>> if [ -n "$inet6" ]; then
>> ${fwcmd} add 2040 deny all from ${inet6} to any in via
>> ${oif6}
>> if [ -n "$onet6" ]; then
>> ${fwcmd} add 2050 deny log all from ${onet6} to
>> any in \
>> via ${iif6}
>> fi
>> fi
>>
>> ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}
>>
>> #
>> # This table is a list of denied addresses that tried to attack us.  Updated
>> # by sshguard.  Anything coming inbound from the outside is blocked.  We
>> also
>> # block anything on the "screw you" lists (two)
>> #
>> ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif}
>> ${fwcmd} add 4010 deny all from any to ${foscam}
>> ${fwcmd} add 4020 deny log all from ${china} to any via ${oif}
>> #
>> # Anything related to RFC1918 or the Manning range that comes in on
>> # the external interface (shouldn't happen) gets tossed immediately, EXCEPT
>> # for RFC1918 stuff coming in via IPSEC.  That we must pass or our IPSEC
>> # gateway will not work.
>> #
>> ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec
>> recv ${oif}
>> ${fwcmd} add 5010 deny

Re: Question that has dogged me for a while.

2017-05-04 Thread Karl Denninger 
On 5/4/2017 12:48, Dr. Rolf Jansen wrote:
> Resolving this with ipfw/NAT may easily become quite complicated, if not 
> impossible if you want to run a stateful nat'ting firewall, which is usually 
> the better choice.
>
> IMHO a DNS based solution is much more effective.
>
> On my gateway I have running the caching DNS resolver Unbound. Now let's 
> assume, the second level domain name in question is example.com, and your web 
> server would be accessed by www.example.com, while other services, e.g. mail 
> are served from other sites on the internet.
>
> In unbound.conf you would place two additional lines before any forwarding 
> directive:
>
> local-zone: "example.com" transparent
> local-data: "www.example.com" A 192.168.1.1
>
> All the clients on the LAN should use the DNS service on the gateway. In the 
> first place Unbound does higher level DNS lookups locally, however, the 
> transparent attribute lets it fall through to its normal recursive or 
> forwarding behaviour in case a given domain could not be resolved locally. 
> For example, the query of www.example.com would return 192.168.1.1 and the 
> query for mail.example.com would be passed either to the forwarder or 
> resolved recursively from the internet.
>
> By this way, local clients would directly access your web server from the 
> inside, no NAT is needed.
>
> IMHO, a DNS server on the gateway got more advantages. It can be used to 
> block access to fraudulent or otherwise useless services on the internet for 
> the whole LAN.
>
> Best regards
>
> Rolf
>
That's another alternative I'm considering which might wind up being the
way I ultimately go

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question that has dogged me for a while.

2017-05-04 Thread Karl Denninger 

On 5/4/2017 12:12, Rodney W. Grimes wrote:
>> 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:
> What is the NAT command running at instance 100?
> Does it have an -alias_address of inside IP of router?
> Are you tryint to use the same Nat instance to do both
> the global internet acess translation and this special
> inside loop back translation?  If so that usually can
> not be made to work.
Aha.  That's probably the problem -- I need a second instance.

Here's the entire salient section:


# Set up the NAT configuration; there are multiple entries that have to
be here
# because we redirect a bunch of ports around so we can see things from the
# outside -- specifically, webcams and the HomeDaemon server.
#
${fwcmd} nat 100 config ip ${oip} log same_ports reset
redirect_port tcp (whole bunch of stuff)

#
# Stop spoofing
#
${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in
via ${oif}
${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif}
if [ -n "$inet6" ]; then
${fwcmd} add 2040 deny all from ${inet6} to any in via
${oif6}
if [ -n "$onet6" ]; then
${fwcmd} add 2050 deny log all from ${onet6} to
any in \
via ${iif6}
fi
fi

${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}

#
# This table is a list of denied addresses that tried to attack us.  Updated
# by sshguard.  Anything coming inbound from the outside is blocked.  We
also
# block anything on the "screw you" lists (two)
#
${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif}
${fwcmd} add 4010 deny all from any to ${foscam}
${fwcmd} add 4020 deny log all from ${china} to any via ${oif}
#
# Anything related to RFC1918 or the Manning range that comes in on
# the external interface (shouldn't happen) gets tossed immediately, EXCEPT
# for RFC1918 stuff coming in via IPSEC.  That we must pass or our IPSEC
# gateway will not work.
#
${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec
recv ${oif}
${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif}

#
# 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

Re: Question that has dogged me for a while.

2017-05-04 Thread Rodney W. Grimes 
> 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:

What is the NAT command running at instance 100?
Does it have an -alias_address of inside IP of router?
Are you tryint to use the same Nat instance to do both
the global internet acess translation and this special
inside loop back translation?  If so that usually can
not be made to work.

> 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.

Yep.

> 
> There has to be a solution to this somewhere and I'm obviously missing
> it. :)
> 
> -- 
> Karl Denninger
> k...@denninger.net 
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/

This is the classical "Loopback Nat Problem" of accessing machines
behind a NAT device that does not do the proper NATTing and 
routing of these packets.   Many small consumer routers got this
wrong for years, just like most ipfw code I have seen.

Most of the consumber devices have been fixed.  The trickery is
you need to NAT packets coming from the inside destined for the
outside IP into the internal IP.  That internal box MUST route
back via the NAT device, so the NATTED addresses for these
packets must be the inside IP of the router.

Your code looks to get this mostly right, but I think you have
missed something someplace.  I dont use kernel nat, and it looks
like you do so you well have to adjust these a little.

inside_ip_router="192.168.10.40"
outside_ip_router="70.16.10.1"
inside_ip_webserver="192.168.10.100"

#natd-vmxZ.conf should just be an empty file for this type of nat
/sbin/natd -f /etc/firewall/natd-vmxZ.conf  -port  -alias_address 
${192.168.10.40} 

Something like
# This takes inside traffic to outside port 80 address and
# remaps it to inside IP of router to send to web

Re: Question that has dogged me for a while.

2017-05-04 Thread Freddie Cash 
On Thu, May 4, 2017 at 9:22 AM, Karl Denninger  wrote:

> 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. :)


​You need to do a double-NAT (or hairpin-NAT or whatever you want to call
it), where you first NAT the destination address on the incoming interface
which will initiate the routing decision for where to send the packet next,
then NAT the source address on the outgoing interface (which can be the
same interface) in order to get the return packets sent back to the correct
gateway.

Something along the lines of:

ipfw nat 100 blah blah blah 
ipfw nat 200 blah blah blah 

ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1  80 in  recv 
ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit 

ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in  recv 
ipfw add nat 200 tcp from 70.16.10.1  80 to 192.168.0.0/16 out xmit https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

2017-05-04 Thread Lee Brown 
On Thu, May 4, 2017 at 9:22 AM, Karl Denninger  wrote:

> 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. :)
>
> Setup DNS to return the internal address when a query is made from an
internal client.
I've never been able to do what you are trying, on a few different
platforms, I forget the reasons now.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"