RP_FILTER runs too late
I finally figured out why my SNAT setup wasn't working. I had 1 in eth0/rp_filter and that was silently breaking it.
This discussion follows the scripts located at website http://blue-labs.org/ , rc.networking and rc.firewalling. Both are live meaning you'll see any changes I make.
Here's the scoop. I run a VPN from here to my colo server...but I don't want all my traffic going through the VPN. So I need to finagle a method of NAT. Now because the NAT code runs behind the routing code, packets are already heading the wrong direction when they get their headers changed. Because of that you need to tag them with a mark and implement routing rules based on that mark. As an aside note, all that could be avoided if SNAT would just be available in PREROUTING.
Ok. Now that packets are flowing through the right interfaces, things look good but wait...the reply packets are vanishing without a trace.
The culprit is the rp_filter on eth0. The packet comes in, gets the header rewritten then gets chomped by rp_filter. I'm not quite sure why because the src is still an external IP and the destination before and after is still an internal IP.
Wouldn't the rp_filter be more effective if it came ahead of the nat code? As it is now, it's useless on that interface.
David
Quoted 23 lines · David Ford
I finally figured out why my SNAT setup wasn't working. I had 1 in eth0/rp_filter and that was silently breaking it.
This discussion follows the scripts located at website
http://blue-labs.org/ , rc.networking and rc.firewalling. Both are live meaning you'll see any changes I make.Here's the scoop. I run a VPN from here to my colo server...but I don't want all my traffic going through the VPN. So I need to finagle a method of NAT. Now because the NAT code runs behind the routing code, packets are already heading the wrong direction when they get their headers changed. Because of that you need to tag them with a mark and implement routing rules based on that mark. As an aside note, all that could be avoided if SNAT would just be available in PREROUTING.
Ok. Now that packets are flowing through the right interfaces, things look good but wait...the reply packets are vanishing without a trace.
The culprit is the
rp_filteron eth0. The packet comes in, gets the header rewritten then gets chomped byrp_filter. I'm not quite sure why because the src is still an external IP and the destination before and after is still an internal IP.
Quoted 4 lines
Wouldn't the
rp_filterbe more effective if it came ahead of the nat code? As it is now, it's useless on that interface.David
I just put up some firewall rules as part of the Dynamic Virtual Private Networking project on sourceforge at http://dvpn.sourceforge.net. It shows both source and destination nat, port forwarding outside of a box, and a couple other fun goodies. Not necessarily your kind of VPN, but maybe it'll help...
I'm not sure what you're trying to do, but I got everything I tried to work...
Rob
Oh I have it working, there is just one workaround requirement and one nit with rp_filter. rp_filter has to be disabled and that is an SNAT item. The workaround for a "pre-routing" snat is to setup ip route rules, tag the packets, and finally nat them. It accomplishes the task I need but is in my opinion a hack.
I'd rather see SNAT available in pre-routing and have rp_filter run against the packet before it hits the netfilter code.
-d
Quoted 37 lines · Rob Landley
Quoted 23 lines · David Ford
I finally figured out why my SNAT setup wasn't working. I had 1 in eth0/rp_filter and that was silently breaking it.
This discussion follows the scripts located at website
http://blue-labs.org/ , rc.networking and rc.firewalling. Both are live meaning you'll see any changes I make.Here's the scoop. I run a VPN from here to my colo server...but I don't want all my traffic going through the VPN. So I need to finagle a method of NAT. Now because the NAT code runs behind the routing code, packets are already heading the wrong direction when they get their headers changed. Because of that you need to tag them with a mark and implement routing rules based on that mark. As an aside note, all that could be avoided if SNAT would just be available in PREROUTING.
Ok. Now that packets are flowing through the right interfaces, things look good but wait...the reply packets are vanishing without a trace.
The culprit is the
rp_filteron eth0. The packet comes in, gets the header rewritten then gets chomped byrp_filter. I'm not quite sure why because the src is still an external IP and the destination before and after is still an internal IP.Quoted 5 lines
Wouldn't the
rp_filterbe more effective if it came ahead of the nat code? As it is now, it's useless on that interface.David
I just put up some firewall rules as part of the Dynamic Virtual Private Networking project on sourceforge at http://dvpn.sourceforge.net. It shows both source and destination nat, port forwarding outside of a box, and a couple other fun goodies. Not necessarily your kind of VPN, but maybe it'll help...
I'm not sure what you're trying to do, but I got everything I tried to work...
Rob
Quoted 2 lines · David Ford
I'd rather see SNAT available in pre-routing and have
rp_filterrun against the packet before it hits the netfilter code.
There is one other problem with rp_filter.... rp_filter violations are S I L E N T. You never know when traffic is dropped because of it. Packets just disappear.
If it generated printk's it would make it a lot easier to track down filtering problems.
-Dan
Signature · 1 line
[-] Omae no subete no kichi wa ore no mono da. [-]
Quoted 3 lines · Dan Hollis
Quoted 2 lines · David Ford
I'd rather see SNAT available in pre-routing and have
rp_filterrun against the packet before it hits the netfilter code.
I believe the reason they put SNAT at the end is that when we're about to send out we no longer care what the source address is, but before that we do, and changing it early would overwrite fields the rest of the network stack is still using. (Same reason dnat happens first thing. If we redirect it, we want it the rest of the network stack to use the NEW destination, and among other things send it out the right interface...)
Principle of "least amount of new code". (Laziness IS one of Larry Wall's Seven Deadly Virtues in programmers...)
Quoted 6 lines
There is one other problem with
rp_filter....rp_filterviolations are S I L E N T. You never know when traffic is dropped because of it. Packets just disappear.If it generated printk's it would make it a lot easier to track down filtering problems.
There is a logging option, but it needs a lot of extra knobs if you ask me. (Logging to a file would be nice. I suspect there's a way to do that but I couldn't find it circa 2.4.3, which is the last time I gave it much thought. Also "log if last rule triggered". Haven't been bothered enough to break open the source other than for debugging purposes, though...)
Quoted 1 line
-Dan
Rob