Routing return NAT traffic based on interface
Peter McAlpine
peter at aoeu.ca
Thu Dec 6 02:15:52 UTC 2012
Ermal this looks to be working perfectly. Thank you so much!
-Peter
On Wed, Dec 5, 2012 at 10:21 AM, Ermal Luçi <eri at freebsd.org> wrote:
>
>
>
> On Wed, Dec 5, 2012 at 3:51 PM, Peter McAlpine <peter at aoeu.ca> wrote:
>
>> First off, thanks for all the suggestions from both of you. My email
>> filters were messed up causing me to miss your replies.
>>
>> On 19 November 2012 18:56, David DeSimone <fox at verio.net> wrote:
>> > If I understand the poster's problem, it is that there could be whole
>> > worlds of other networks behind $int_if, and he is not able to predict
>> > what IP addresses should be used to match that traffic; in fact, it is
>> > merely the fact that the traffic is arriving on $int_if that indicates
>> > it shoudl be NAT'd.
>> ^^ this is the problem exactly.
>>
>> Here's the config I have:
>> tun_if = "tap3"
>> ext_if = "xn0"
>> set skip on lo
>> nat on $ext_if from !$ext_if:network to any -> $ext_if
>> pass in on $tun_if from $tun_if:network to any keep state
>> pass out on $ext_if from any to any keep state
>>
>
> Maybe this can help, by writing the rules as follows.
>
> pass in on $tun_if from any to any tag TUNIFACE keep state
> pass in on $ext_if route-to ($tun_if $gateway_tun_if) from any to !self
> tag TUNIFACE keep state
>
> pass out on $tun_if reply-to ($ext_if $ext_if_gateway) from any to any
> tagged TUNIFACE keep state
> pass out on $ext_if reply-to ($tun_if $gateway_tun_if) from any to any
> tagged TUNIFACE keep state
>
> Then keep your other rules going...
>
>
>> I've attached a simple network diagram. If I ping google.com from a.b.c.d
>> the icmp traffic on 'server' goes out ext_if NAT'd, then comes back from
>> google.com, but then 'server' is trying to send it back out ext_if again
>> because 'server''s default route is the Internet.
>>
>> I can get the return traffic to go down the tunnel by manually adding a
>> route on 'server' to send traffic for a.b.c.0/24 down the tunnel, but then
>> I need to be aware of what all the networks behind 'client' are, and I
>> don't want to have to do that.
>>
>> Thanks again for all the ideas/input!
>> -Peter
>>
>> On Mon, Nov 19, 2012 at 7:46 PM, Kevin Wilcox <kevin.wilcox at gmail.com
>> >wrote:
>>
>> > On 19 November 2012 18:56, David DeSimone <fox at verio.net> wrote:
>> >
>> > > This doesn't seem right, because even traffic coming in via the
>> external
>> > > interface will have its target IP changed to be the router, even if
>> > > it is destined for some other place. Previously you were using "from
>> > > $int_if:network" to prevent this from happening to other traffic, but
>> > > without that restriction, every packet would be subject to NAT.
>> >
>> > My assumption was that the traffic coming in on the external interface
>> > is already destined for the outside IP of the router, unless he's
>> > doing some really funky stuff on both sides ;)
>> >
>> > It sounded like he wanted to NAT anything coming from the inside
>> > interface and then anything on the outside that wasn't return NAT
>> > traffic was supposed to terminate on the router, but I've been known
>> > to have clogged ears and awfully poor eyesight.
>> >
>> > kmw
>> >
>>
>> _______________________________________________
>> freebsd-pf at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>>
>>
>
>
> --
> Ermal
>
More information about the freebsd-pf
mailing list