Re: a problem with pf's NAT...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: a problem with pf's NAT...

Marcus MERIGHI
Moving topic to misc@. Or do you think NAT is broken?

[hidden email] (zje.net.cn), 2016.01.19 (Tue) 03:37 (CET):

> Hi, i'm tesing the NAT with the pf on OpenBSD 5.8, but i can not make it successful.There is a server with pf having a internal IP 10.0.11.200 and external IP 61.xxx.xx.xx,
> then, i make a pf.conf with contents like below(having enable IP forwarding) :
>
>
> #my define
> int_if = "de1"    #10.0.11.200
> ext_if = "de2"   #61.xxx.xx.xx
> int_net = "10.0.11.0/24"
> #my rules
> pass out on $ext_if inet from $int_if:network to any nat-to $ext_if
>
>
>
> after apply the config, i test working of the NAT from a client with
> IP 10.0.11.19 (who's gateway refer to 10.0.11.200),
> then i can not visit the external service such as a website,
> when i try to "netstat/n" on the client, get results as below:
>
> now, i need help for my problem, thanks for your reply.

your lovely dos box image shows that the connection is in SYN state; I
guess your client (10.0.11.19) just gets blocked when entering the
firewall via de1.

Bye, Marcus

Reply | Threaded
Open this post in threaded view
|

Re: a problem with pf's NAT...

Peter Nicolai Mathias Hansteen
> [hidden email] (zje.net.cn), 2016.01.19 (Tue) 03:37 (CET):
> > Hi, i'm tesing the NAT with the pf on OpenBSD 5.8, but i can not make it successful.There is a server with pf having a internal IP 10.0.11.200 and external IP 61.xxx.xx.xx,
> > then, i make a pf.conf with contents like below(having enable IP forwarding) :
> >
> > #my define
> > int_if = "de1"    #10.0.11.200
> > ext_if = "de2"   #61.xxx.xx.xx
> > int_net = "10.0.11.0/24"
> > #my rules
> > pass out on $ext_if inet from $int_if:network to any nat-to $ext_if

if those rules are your entire ruleset, forwarding is enabled and all
interfaces involved are correctly set up (not forgetting netmasks), this
should just work.

First, do

~$ sysctl net.inet.ip.forwarding  

if the response isn't exactly

net.inet.ip.forwarding=1

that's at least one of your problems.

Next, check that both de1 and de2 are in fact configured and functional
(as in, ifconfig output should include at least "UP" and "RUNNING"),
check that you can ping the configured address on the gateway itself
and from the client, check that netmasks match on both client and
gateway, check the client's routing, and of course check that your
pf.conf doesn't have one or more 'block' statements you haven't shown us.

And as Marcus said earlier,
 
> your lovely dos box image shows that the connection is in SYN state; I
> guess your client (10.0.11.19) just gets blocked when entering the
> firewall via de1.

This means that your client has a route for the target address that it considers valid,
however in that state it has yet to receive *anything* back from the intended
target address. Going through the steps I outlined in the previous paragraph
will tell you why that is so.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: a problem with pf's NAT...

Michael Wilson
On Tue, 19 Jan 2016 09:14:08 +0100
"Peter N. M. Hansteen" <[hidden email]> wrote:

> > [hidden email] (zje.net.cn), 2016.01.19 (Tue) 03:37 (CET):  
> > > Hi, i'm tesing the NAT with the pf on OpenBSD 5.8, but i can not
> > > make it successful.There is a server with pf having a internal IP
> > > 10.0.11.200 and external IP 61.xxx.xx.xx, then, i make a pf.conf
> > > with contents like below(having enable IP forwarding) :
> > >
> > > #my define
> > > int_if = "de1"    #10.0.11.200
> > > ext_if = "de2"   #61.xxx.xx.xx
> > > int_net = "10.0.11.0/24"
> > > #my rules
> > > pass out on $ext_if inet from $int_if:network to any nat-to
> > > $ext_if  
>
> if those rules are your entire ruleset, forwarding is enabled and all
> interfaces involved are correctly set up (not forgetting netmasks),
> this should just work.
Maybe I missed something, but what about:

        pass in on $int_if from $int_if:network

>
> First, do
>
> ~$ sysctl net.inet.ip.forwarding  
>
> if the response isn't exactly
>
> net.inet.ip.forwarding=1
>
> that's at least one of your problems.
>
> Next, check that both de1 and de2 are in fact configured and
> functional (as in, ifconfig output should include at least "UP" and
> "RUNNING"), check that you can ping the configured address on the
> gateway itself and from the client, check that netmasks match on both
> client and gateway, check the client's routing, and of course check
> that your pf.conf doesn't have one or more 'block' statements you
> haven't shown us.
>
> And as Marcus said earlier,
>  
> > your lovely dos box image shows that the connection is in SYN
> > state; I guess your client (10.0.11.19) just gets blocked when
> > entering the firewall via de1.  
>
> This means that your client has a route for the target address that
> it considers valid, however in that state it has yet to receive
> *anything* back from the intended target address. Going through the
> steps I outlined in the previous paragraph will tell you why that is
> so.

Reply | Threaded
Open this post in threaded view
|

Re: a problem with pf's NAT...

Stuart Henderson
On 2016-01-19, Michael Wilson <[hidden email]> wrote:

> On Tue, 19 Jan 2016 09:14:08 +0100
> "Peter N. M. Hansteen" <[hidden email]> wrote:
>
>> > [hidden email] (zje.net.cn), 2016.01.19 (Tue) 03:37 (CET):  
>> > > Hi, i'm tesing the NAT with the pf on OpenBSD 5.8, but i can not
>> > > make it successful.There is a server with pf having a internal IP
>> > > 10.0.11.200 and external IP 61.xxx.xx.xx, then, i make a pf.conf
>> > > with contents like below(having enable IP forwarding) :
>> > >
>> > > #my define
>> > > int_if = "de1"    #10.0.11.200
>> > > ext_if = "de2"   #61.xxx.xx.xx
>> > > int_net = "10.0.11.0/24"
>> > > #my rules
>> > > pass out on $ext_if inet from $int_if:network to any nat-to
>> > > $ext_if  
>>
>> if those rules are your entire ruleset, forwarding is enabled and all
>> interfaces involved are correctly set up (not forgetting netmasks),
>> this should just work.
> Maybe I missed something, but what about:
>
> pass in on $int_if from $int_if:network

There is an implicit "pass flags any no state" rule. So the incoming
packets should be accepted, and I'd expect this to work, though it is
not a *good* configuration.

Be explicit: make your first rule "block" or "block log". Otherwise
it's easy to miss a case and then you're at risk of running into
problems with TCP sequence number checks and window scaling when
you add rules later.

Reply | Threaded
Open this post in threaded view
|

Re: ??????a problem with pf's NAT...

Peter Nicolai Mathias Hansteen
In reply to this post by Peter Nicolai Mathias Hansteen
On Thu, Jan 21, 2016 at 12:25:16AM +0800, zje.net.cn wrote:
> sorry, i had tried many times with inspecting all settings, but can't make the NAT well done yet.In this environment, my haproxy is working well, so i think the base network settings are good

As long as you're not providing any further information, we're left to
speculate as to the real reason.

I've already told you the basic steps, but as to the PF part, I'd start with a block, then open the stuff I need, as in

int_if = "de1"    #10.0.11.200
ext_if = "de2"   #61.xxx.xx.xx
int_net = "10.0.11.0/24"

block
match out on egress inet nat-to $ext_if
pass inet from $int_net

(hint: careful where you block and where you pass)

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: ??????a problem with pf's NAT...

Marko Cupać
On Thu, 21 Jan 2016 09:19:32 +0100
"Peter N. M. Hansteen" <[hidden email]> wrote:


> I've already told you the basic steps, but as to the PF part, I'd
> start with a block, then open the stuff I need, as in

Or even better, start with 'block log', and inspect blocked traffic in
real time with:
# tcpdump -n -e -q -ttt -i pflog0

Or see what has been blocked in the past with:
# tcpdump -n -e -q -ttt -r /var/log/pflog
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Reply | Threaded
Open this post in threaded view
|

Re: ??????a problem with pf's NAT...

Peter Nicolai Mathias Hansteen
On Thu, Jan 21, 2016 at 10:14:25AM +0100, Marko Cupa?? wrote:
> Or even better, start with 'block log', and inspect blocked traffic in
> real time with:
> # tcpdump -n -e -q -ttt -i pflog0

Very true. Or even add log (all) to all rule if you want all packets. The main point remains,
logging is essential to debugging, which is what the original poster needs to do.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.