My setup is a pair of OpenBSD 4.8 routers, with 1 dedicated (fxp0) NIC in each
to carry pfsync traffic, and 2 NIC (bge0,1) with multiple VLANs to carry normal
traffic.
I have pfsync+carp set up and I see the carp1-8 (8 distinct VLANs, including
both internal and upstream) being populated and at any one time only one of the
two routers has 'master' while the other one has 'backup'.
Initially this was my first non-macro, non-options rule within pf.conf:
match out log on egress inet from !egress:network to any nat-to carp6
block in log
pass in log quick inet proto icmp all icmp-type { echoreq, unreach }
pass proto tcp from carp5:network to port { http, https}
>From 'tcpdump -e -n -i pflog0', I can see that packets are matching both the
>'nat-to' and the 'pass' rules, but on the egress network they are being
>presented with the workstations carp5:network adddress, not the carp6 address.
What baffles me is this, if I change the 'match' to a 'pass', ping or
traceroute's icmp traffic does get NATted, but web browser's traffic is passed
to the egress network, but does not get NATted, so the revised fragment of
pf.conf is:
pass out log on egress inet from !egress:network to any nat-to carp6
block in log
pass in log quick inet proto icmp all icmp-type { echoreq, unreach }
pass proto tcp from carp5:network to port { http, https}
How should I diagnose this?
Is there a mechanism to follow a specific packet step by step through the pf
rules to understand why each one is selected?
Is there any rule which doesn't include 'nat-to' which strips off the 'nat-to'
status from the 'match'?
This first line is the ONLY line where the string 'nat-to' exists.
