On Apr 10, 2005 1:13 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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.
Maybe you need to add the 'reply-to' option to all of your 'pass-in' statements?
