|
|
|||
Help with OpenBSD 4.8 and NAT
Hi everybody,
I decided to upgrade my Openbsd 4.5 to 4.8, I use it only to split my internet connection using NAT. In 4.5 everything is working fine, but in version 4.8 they changed the syntax for the NAT rules in pf.conf. Here is my working 4.5 pf.conf: Code:
# cat pf.conf int_if="hme0" ext_if="pppoe0" set block-policy return set loginterface $ext_if set skip on lo match on pppoe0 scrub (max-mss 1440) nat on $ext_if from !($ext_if) to any -> ($ext_if) Code:
ext_if="pppoe0" int_if="xl1" set block-policy return set loginterface $ext_if set skip on lo match on pppoe0 scrub (max-mss 1440) match out on $ext_if from !($ext_if) nat-to ($ext_if) Thanks in advance |
|
|||
Quote:
I reinstalled but I did think to activate IP forwarding in sysctl.conf. Also I forgot to say the pppoe internet connection is working on the firewall computer, so the problem is probably pf-related... |
|
|||
What if you add "to any" after the from clause and before nat-to. Looking at the grammar in the man page, it doesn't look optional.
|
|
|||
In one of those examples, you define $int_if as hme0 but in the other it's xl1.
Other than that, consider adding another pass rule.. or changing the match rule to a pass. pass out on $ext_if from !($ext_if) to any nat-to ($ext_if) ...or match+pass: match out on $ext_if from !($ext_if) to any nat-to ($ext_if) pass out on $ext_if all Good luck. |
|
|||
Quote:
Code:
pass out on $ext_if from !($ext_if) to any nat-to ($ext_if) Now I will try to add security rules to block access from the outside.. I'm a newbie so it won't be easy... |
|
|||
For we casual pf users, could someone explain why this worked for him?
Was it the addition of "to any" or was it that having an explicit pass rule was necessary for the nat-to property of the match rule to be used? So if you have match rules adding one of these properties (making them sticky as the man page puts it) for later pass rules, they do not get applied if you fall through to the default pass rule? Or is it that the default pass rule is effectively a prior rule, so match rules don't apply to it because the match conceptually comes after the unwritten default rule? |
|
|