[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Source-based routing (sometimes)
Hello. Unless I'm mistaken about what it is that you're doing, this
setup sounds similar to one I have at my office. I have a nat such that
anything going out to the general Internet goes through the nat, using pf,
and anything going across my tunnel goes through the tunnel interface
without natting. If you nat all packets that go through the external
interface, it seems like you wouldn't run into the problem you describe.
The tunneled packets have the correct source address because they're
encapsulated by your nat box. Packets which don't go through your tunnel
get natted, and so by definition have the correct address. I do this
without source routing at all. The trick, I suspect, is to insure that you
never engage in assymetric routing such that you try to source packets from
addresses that would be inside the tunnel and expect to send them out
through your local connection and have return traffic come back through the
Hope this helps.
On Nov 24, 10:59am, Michael Graff wrote:
} Subject: Source-based routing (sometimes)
} I have what is an overly complicated home setup. My ISP provides me
} with only one address, and so I have to NAT for the boxes in my house.
} I also have a tunnel, which provides IPv6 and a ipv4 /27 for some of my
} machines. Not everything is tunneled, most things are in fact NAT'd.
} Until recently this all just worked because my ISP did not do ingress
} filtering. However, they seem to have finally decided to implement
} this, and so packets with incorrect source addresses are now being
} blocked. I applaud them for finally implementing this very useful
} anti-spoof technique, but I do wish they'd have exempted me. :)
} What I want is simple to describe, but very complicated to implement. I
} want all packets with source address 18.104.22.168/27 to go out gif0, and
} all other packets to follow normal destination-based routing.
} I tried adding this to my pf.conf:
} pass out on rtk0 route-to ( gif0 22.214.171.124 ) from 126.96.36.199/24 to
} It seems that the route-to is ignored.
} I tried spinning up a srt0 interface and using it. It did the right
} thing and set 188.8.131.52/27 out gif0, but I had to add a 0.0.0.0/0
} (default-like) destination to rtk0, which then bypassed the pf-based
} Anything else I should try here?
>-- End of excerpt from Michael Graff
Main Index |
Thread Index |