Re: pf + ipv6 + keep state - any known issues?
Are you using antispoofing rules on your external interface? If you've got something like this in your ruleset: antispoof log quick for $ext_if Then it will expand into a series of rules containing the following when you load them: Thank you for responding! No, this is not the issue. I *am* performing antispoof on my physical interface, but not on the tunnel interface. After some further investigation my current theory is that I have run into the trouble with pf and a packet traversing an interface twice. Having a 'keep state' on the *incoming* direction results in a state entry according to pfctl. But no state entry for the 'keep state' in the outgoing direction. The result being that while packets coming into port 22 are allowed and state set up, but the responding packets (to some random source port) are NOT allowed because the outgoing direction yielded no state entry. I am not sure what the behavior is supposed to be with a packet traversing the same interface twice, except I have seen references to the effect of don't be stupid, don't do that, get another NIC (for the typical firewall/gateway case). Except in this case that does not apply, even if you agree with the sentiment to begin with. Can anyone confirm or deny whether double traversal *IS* supposed to work without difficulties/special cases on current versions of pf/FreeBSD? Thanks! -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf + ipv6 + keep state - any known issues?
Peter Schuller wrote: Hello, I am using pf on a 6.1 machine. I have a tunneling interface (gif0) for my IPv6 feed. The problem I am having is connecting to myself in spite of firewalling. I am allowing traffic on port 22 to my public ipv6 address. I am also allowing all outgoing traffic on the tunneling interface, with 'keep state'. ping6:ing myself works, but connecting to port 22 does not. The intial SYN gets through and is responded to by an ACK, but that ACK is seemingly dropped. This inspite of the fact that 'pfctl -s state' shows a tracked connection for the relevant port pair. I can work around it by allowing all packets from my own IP on the tunneling interface, but as far as I know this should not be required. That is, connection tracking should be working even for local connections on a particular interface - correct? Note that connecting to port 22 works perfectly from outside IP:s (I had someone external verify this) without any special casing of the rules. That is, I only have the usual rules for allowing the incoming packets to port 22, and the rule allowing outgoing packets with 'keep state'. The fact that this allows successful establishment to port 22 by an external party suggests to me that I have not made some trivial misstake in the rule - yet connections to myself do not work. My question is whether there are any known issues that this sounds like - or of course if there is some reason why this is not supposed to work by design. Are you using antispoofing rules on your external interface? If you've got something like this in your ruleset: antispoof log quick for $ext_if Then it will expand into a series of rules containing the following when you load them: block drop in log quick on ! em0 inet from 12.34.56.72/29 to any Where 12.34.56.72/29 is the address of the network your external interface (em0) is attached to. (Although the example I show is for IPv4, exactly the same applies for IPv6) End result is that you cannot connect to a service listening on your external IP from the box itself, because that does not result in inbound packets traversing the em0 interface. And it's a 'quick' rule, so you can't override it by adding a more specific rule later in the ruleset. In general, use antispoof for the loopback as a standard part of any ruleset you write. Antispoof on other interfaces should be considered carefully and only applied where necessary. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
pf + ipv6 + keep state - any known issues?
Hello, I am using pf on a 6.1 machine. I have a tunneling interface (gif0) for my IPv6 feed. The problem I am having is connecting to myself in spite of firewalling. I am allowing traffic on port 22 to my public ipv6 address. I am also allowing all outgoing traffic on the tunneling interface, with 'keep state'. ping6:ing myself works, but connecting to port 22 does not. The intial SYN gets through and is responded to by an ACK, but that ACK is seemingly dropped. This inspite of the fact that 'pfctl -s state' shows a tracked connection for the relevant port pair. I can work around it by allowing all packets from my own IP on the tunneling interface, but as far as I know this should not be required. That is, connection tracking should be working even for local connections on a particular interface - correct? Note that connecting to port 22 works perfectly from outside IP:s (I had someone external verify this) without any special casing of the rules. That is, I only have the usual rules for allowing the incoming packets to port 22, and the rule allowing outgoing packets with 'keep state'. The fact that this allows successful establishment to port 22 by an external party suggests to me that I have not made some trivial misstake in the rule - yet connections to myself do not work. My question is whether there are any known issues that this sounds like - or of course if there is some reason why this is not supposed to work by design. Thank you, -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
