On 2013/06/04 02:01, Mike Belopuhov wrote: > On 4 June 2013 00:49, 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? > > > > 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
