PF PF rule "route-to" syntax error

[chk.jxcn]

For singe port/service forwards use 'rdr':
pf.conf(5)

     rdr   The packet is redirected to another destination and possibly a
           different port.  rdr rules can optionally specify port ranges
           instead of single ports.  rdr ... port 2000:2999 -> ... port 4000
           redirects ports 2000 to 2999 (inclusive) to port 4000.  rdr ...
           port 2000:2999 -> ... port 4000:* redirects port 2000 to 4000, 2001
           to 4001, ..., 2999 to 4999.

The host that receives the forwarded traffic of course still needs to have the proper routes in place to send out reply traffic.


'route-to' should _never_ be used for actual routing, as the replies won't be affected by the rule. This will lead to very weird and almost non-debuggable asymmetric routing problems and should only be used for *very* special and temporary use cases (e.g. during transitions of IPs/hosts).

But it was writing on manual, and even could apply config successful, but really didn't take effect, I guess this make user more confused than the "routing problem".

Manual should metion this: route-to is still not implement, choose rtable if someone try to routing packet base on source address in pf.

 

[Alex Seitsinger]

From what I get from pf.conf() I'd try:

pass in on $int_if route-to ($ext_gw) proto tcp port https from $lan_net

And yes, please also post the error message when you have tried.

You may need to include 'inet' when you're specifying source and/or destination port(s).

 

[Jose]

Meet the same issue, but sad to say, the route-to never implement in FreeBSD, the patch of route-to only available in pfsense.
Original patch (many fix after that)

Importing pfSense patch pf_route_to_daemon_friendly.diff · pfsense/FreeBSD-src@7bcb50d

(cherry picked from commit 3c8160375dd179622715dfb06d124f0a2f61ffa9)

github.com

So you're saying "route-to" is not implemented at all on Freebsd based on your analysis of some random pfsense patch?

Manual should metion this: route-to is still not implement, choose rtable if someone try to routing packet base on source address in pf.

Going to need more than your say-so to believe that route-to is actually broken. Do you have a test case? Examples using ipfw don't count.

Also, pf should not be used for routing. See earlier in this thread:

Rule of thumb, a firewall is not a router. So don't try to route with PF. Use route(8) for that. You can add routes to specific address:
route add 1.2.3.4/32 1.1.1.1
Traffic destined for 1.2.3.4/32 will be sent to 1.1.1.1 for further routing.

 

[mer]

So you're saying "route-to" is not implemented at all on Freebsd based on your analysis of some random pfsense patch?

Almost seems like the patch would have references to the files changed, then one could got to pure FreeBSD git repo and exam source code.

 

[Jose]

Almost seems like the patch would have references to the files changed, then one could got to pure FreeBSD git repo and exam source code.

The code is a little hard to follow because "route-to" turns out to be the default route action (as opposed to reply-to and dup-to). The magic happens here. Basically, if r->rt is set at all, pf_route() is called. That function does the routing, replying, etc. Again, the string "route-to" doesn't appear because it's the default route action.

That code appears to have been in pf(4) for 10 years.

That patch he linked appears to remove NAT from packets that are routed-to. I don't know what all the implications of doing such would be. I certainly would not apply it blindly.

 

[mer]

That patch he linked appears to remove NAT from packets that are routed-to. I don't know what all the implications of doing such would be. I certainly would not apply it blindly.

I was rereading the man page for openbsd on route-to, it defnitely sounded like it bypassed NAT and routing tables. "receive a packet for A.B.C.D but route-to says send to interface X". that implies to me that something on the otherside of interface X is actually listening for A.B.C.D, kind of like adding an alias on an interface for jails or VMs.

So I understand the mechanics, but am not seeing the utility of the option.

 

[Jose]

So I understand the mechanics, but am not seeing the utility of the option.

Same here, since the target host might not have a route back to the source of the packets. The "reply-to" and "dup-to" options make more sense to me.

 

[chk.jxcn]

The code is a little hard to follow because "route-to" turns out to be the default route action (as opposed to reply-to and dup-to). The magic happens here. Basically, if r->rt is set at all, pf_route() is called. That function does the routing, replying, etc. Again, the string "route-to" doesn't appear because it's the default route action.

That code appears to have been in pf(4) for 10 years.

That patch he linked appears to remove NAT from packets that are routed-to. I don't know what all the implications of doing such would be. I certainly would not apply it blindly.

Sorry about that, I test route-to with nat enable (like the example in pf FAQ), but it not works, after check source code of pf, didn't find anything about route-to compare with pf source code in OpenBSD, then I misunderstand it didn't implement.
If route-to bypass nat, then the suggest of don't use this option maybe truth.

 

[chk.jxcn]

I was rereading the man page for openbsd on route-to, it defnitely sounded like it bypassed NAT and routing tables. "receive a packet for A.B.C.D but route-to says send to interface X". that implies to me that something on the otherside of interface X is actually listening for A.B.C.D, kind of like adding an alias on an interface for jails or VMs.

So I understand the mechanics, but am not seeing the utility of the option.

After recognize the route-to bypass nat, I try route the packet by add a tag.
And it works now, thank you.

ext_if = "vmx0"
wg_if = "wg0"
wg_net = $wg_if:network
vpn_gw = "192.168.2.119"

nat on $ext_if from $wg_net to any tag VPN_NAT -> ($ext_if)
#pass in on $wg_if route-to ($ext_if $vpn_gw) from $wg_net  # this not works, take from pf FAQ
pass out on $ext_if route-to ($ext_if $vpn_gw) tagged VPN_NAT