[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Headache with dual WAN and "source route verification"



> On Apr 8, 2005 3:49 PM, [email protected] wrote:
>> I am running pf in an environment with two WAN connections,
>
> I noticed you don't mention the specific version of OpenBSD?
>
>> and pf is configured to load-balance outgoing traffic.
>> This worked nicely for quite a while, then one ISP turned on
>> "source route verification" on their DSL circuits. This causes
>> any packets coming into their equipment to get dropped if the
>> source address is not within the block that they have assigned.
>
> This sort of anti-spoofing by ISPs is generally a very good thing
> for the Internet as a whole.  That said,  I'm in the same boat --
> two ISP uplinks, one with an assigned subnet, and the other
> doing anti-spoofing filtering on packets injected by customers.
>
>
>> When state is established by an incoming connection,
>> none of my rules to redirect WAN traffic are effective and
>> some connections cannot be established.
>>
>> What are my options to ensure that _only_ traffic with a
>> source address belonging to ext_if2 goes out ext_if2 ?
>
> The trick is to change all of your lines that are currently of the
> form :
>     pass in on $ext_if1 inet proto . . . keep state
>     pass in on $ext_if2 inet proto . . . keep state
>
> By including an option specifying the 'reply-to' interface:
>
>     pass in on $ext_if1 reply-to $ext_if1 inet proto . . . keep state
>     pass in on $ext_if2 reply-to $ext_if2 inet proto . . . keep state
>
> This instructs pf to ignore the system routing table, and instead
> set the next hop for replies associated with a particular state
> entry to go out via the interface specified in the 'reply-to' option.
OpenBSD 3.6-stable
Beautiful - reply-to seems perfectly suited to address the problem. For some
reason, this change breaks inbound mail (I think all inward connections)
completely. The inbound connection arrives at the WAN1 interface. I see it get
passed to the mail server on the LAN interface, and the mail server responds.
That's the last I see of the response. It does not go out either WAN interface
and is does not show up in pflog0. Perhaps I need some better debugging
techniques to learn where and why the response is dumped. To my simple
understanding, the initial inbound connection should have created a state for
the response, which would have a free pass back out the firewall.
George
Kevin Kadow