Re: ipsec / PF received-on
On 4 June 2013 00:49, Stuart Henderson wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? > but if you do the same w/o 'received-on' then packets would get natted anyways, won't they?
Re: ipsec / PF received-on
Stuart Henderson [s...@spacehopper.org] wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? >From your description, i'd think ipsec should not be processing these packets, PF should get them first.
Re: ipsec / PF received-on
On 2013/06/04 02:01, Mike Belopuhov wrote: > On 4 June 2013 00:49, Stuart Henderson wrote: > > On a router running PF and isakmpd, I have a rule like this: > > > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > > > I was surprised to find this being applied to packets received on vlan5 > > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) > > packets > > (as in, generated on the router itself, not actually themselves received on > > vlan5) end up getting natted. > > > > What does anyone else think...expected or not? > > > > but if you do the same w/o 'received-on' then packets would get natted > anyways, won't they? it's special to received-on - replace it with 'from 10.15.5.0/24' and the proto esp packets don't get natted. 01:40:23.273366 esp aa.145 > xx.66 spi 0x13800d75 seq 747 len 104 < change pf rule here > 01:40:24.278672 esp aa.146 > xx.66 spi 0x13800d75 seq 748 len 104 On 2013/06/03 17:03, Chris Cappuccio wrote: > Stuart Henderson [s...@spacehopper.org] wrote: > > On a router running PF and isakmpd, I have a rule like this: > > > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > > > I was surprised to find this being applied to packets received on vlan5 > > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) > > packets > > (as in, generated on the router itself, not actually themselves received on > > vlan5) end up getting natted. > > > > What does anyone else think...expected or not? > > From your description, i'd think ipsec should not be processing these packets, > PF should get them first. > oh, there's some other natting too, this probably is a bit of a corner case match out on enc0 from 10.15.5.0/24 to 192.168.40.0/21 nat-to $cip_ip ike esp from $cip_ip (10.15.5.0/24) to 192.168.40.0/21 local $localip peer $peer
Re: ipsec / PF received-on
On Mon, Jun 03, 2013 at 11:49:58PM +0100, Stuart Henderson wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? > Question, would you expect the ipsec packets to match against this rule? match out on pppoe0 inet all received-on enc0 nat-to $someip As in should we change the received interface when we hit ipsec? Think carefully since this path is edged by dragons and deep dark rabbit holes. -- :wq Claudio
Re: ipsec / PF received-on
On 4 June 2013 02:48, Stuart Henderson wrote: > On 2013/06/04 02:01, Mike Belopuhov wrote: >> On 4 June 2013 00:49, Stuart Henderson wrote: >> > On a router running PF and isakmpd, I have a rule like this: >> > >> > match out on pppoe0 inet all received-on vlan5 nat-to $someip >> > >> > I was surprised to find this being applied to packets received on vlan5 >> > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) >> > packets >> > (as in, generated on the router itself, not actually themselves received on >> > vlan5) end up getting natted. >> > >> > What does anyone else think...expected or not? >> > >> >> but if you do the same w/o 'received-on' then packets would get natted >> anyways, won't they? > > it's special to received-on - replace it with 'from 10.15.5.0/24' and > the proto esp packets don't get natted. > if you add the "from" then you're changing the filter to exclude those packets. received-on just looks at the rcvif stored in the mbuf packet header and since it's not changed by anything you're able to match those packets. now if you want to make ipsec packets look like they've originated on the host itself, you'd need to reset the rcvif.
Re: ipsec / PF received-on
On 04/06/2013, at 11:22 AM, Claudio Jeker wrote: > On Mon, Jun 03, 2013 at 11:49:58PM +0100, Stuart Henderson wrote: >> On a router running PF and isakmpd, I have a rule like this: >> >> match out on pppoe0 inet all received-on vlan5 nat-to $someip >> >> I was surprised to find this being applied to packets received on vlan5 >> and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets >> (as in, generated on the router itself, not actually themselves received on >> vlan5) end up getting natted. >> >> What does anyone else think...expected or not? >> > > Question, would you expect the ipsec packets to match against this rule? > match out on pppoe0 inet all received-on enc0 nat-to $someip > > As in should we change the received interface when we hit ipsec? > Think carefully since this path is edged by dragons and deep dark > rabbit holes. there is precedence for virtual interfaces to overwrite the rcvif on the way through. eg, em0 could become trunk0 which could become vlan0. in this particular case though (ipsec gateway) id argue encapsulation by ipsec should clear the rcvif. is there any error handling for ipsec packets that relies on it? dlg
