Re: reply-to for blocked packets
Em 04-08-2015 04:52, Kapetanakis Giannis escreveu: I've already have rules for outgoing traffic that utilize route-to. However this applies only for new packets generated from host itself. It does not match on returns. Not necessarily true. You can filter on your outgoing interfaces as this: pass out on $ext_iface1 from ($ext2_iface) route-to ($ext_iface1 $ext1_gw) keep state pass out on $ext_iface2 from ($ext1_iface) route-to ($ext_iface1 $ext1_gw) keep state This will enforce that any rogue packets going out on the wrong if, gets routed to the right gw. Of course this is for natted packets, since I using the external interfaces ip addresses. For routed packets, you will need to write more specific rules. Dropping instead of return would definitely stop it. Routing domains indeed seems they only solution in case I want returns. Not sure if they are the only solution, but it seems to be the easiest one to deploy, in your case. if block rules with return do create a state, why do they not respect the reply-to ? Now you got me. I would need to read the source to answer you, but I believe that reply-to ends up only working for pass rules, not block ones. Cheers, Giancarlo Razzolini
Re: reply-to for blocked packets
On 03/08/15 16:45, Giancarlo Razzolini wrote: Em 03-08-2015 05:23, Kapetanakis Giannis escreveu: Is there a way to sort this out and route packets to the correct interface? You can try to create enforcing rules. Create 2 rules in your outgoing interfaces that, when they detect a packet leaving a interface but it should be on the other, you force route-to rules (not reply-to) on them. Block rules with return do create states, but as soon as the packet is sent, they enter in TIME_WAIT status (as it should be). Do you really, really, need to return the packets? Perhaps in your case you can benefit from routing domains. Cheers, Giancarlo Razzolini I've already have rules for outgoing traffic that utilize route-to. However this applies only for new packets generated from host itself. It does not match on returns. Dropping instead of return would definitely stop it. Routing domains indeed seems they only solution in case I want returns. Thanks G ps. if block rules with return do create a state, why do they not respect the reply-to ?
reply-to for blocked packets
Hi, I have a server with 2 vlan interfaces + 2 carped interfaces. Replies for blocked connections (tcp reset or icmp port unreachable) are coming out through the wrong interface (ie always on default gw). Near the end of my pf.conf I have the following rules: @49: block return in quick log on $vlan10_if from local_net reply-to ($vlan10_if $vlan10_gw) @50: block return in quick log on $vlan20_if from local_net reply-to ($vlan20_if $vlan20_gw) Default gw is on vlan10 interface. When I try to connect on second interface (vlan20) the returns are coming from first interface (vlan10). pflog: Aug 03 11:12:17.442169 rule 50/(match) block in on vlan20: 10.1.1.1.50818 10.1.20.3.4000: S 644386329:644386329(0) win 14600 mss 1460,sackOK,timestamp 861260278 0,nop,wscale 4 (DF) [tos 0x10] tcpdump on vlan20: 11:19:17.673638 10.1.1.1.50834 10.1.20.3.4000: S 381640153:381640153(0) win 14600 mss 1460,sackOK,timestamp 861365336 0,nop,wscale 4 (DF) [tos 0x10] tcpdump on vlan10: 11:19:17.673656 10.1.20.3.4000 10.1.1.1.18.50834: R 0:0(0) ack 381640154 win 0 (DF) [tos 0x10] The problem must be that there is no state created (from pf.conf(5) reply-to is useful only in rules that create state) Similar for udp packets (icmp port unreachable) Is there a way to sort this out and route packets to the correct interface? Thanks G
Re: reply-to for blocked packets
Em 03-08-2015 05:23, Kapetanakis Giannis escreveu: Is there a way to sort this out and route packets to the correct interface? You can try to create enforcing rules. Create 2 rules in your outgoing interfaces that, when they detect a packet leaving a interface but it should be on the other, you force route-to rules (not reply-to) on them. Block rules with return do create states, but as soon as the packet is sent, they enter in TIME_WAIT status (as it should be). Do you really, really, need to return the packets? Perhaps in your case you can benefit from routing domains. Cheers, Giancarlo Razzolini
