On Aug 30, 2010 at 3:36 PM, Henning Brauer wrote: > > why don't you look at the real interfaces instead of speculating. > > pflog is a bit messy, but that's another story hopefully solved soon. > > -- > Henning Brauer, h...@bsws.de, henn...@openbsd.org > BS Web Services, http://bsws.de > Full-Service ISP - Secure Hosting, Mail and DNS Services > Dedicated Servers, Rootservers, Application Hosting >
I took your advice and ran a log on both external interfaces in addition to pflog0. What I found was that there was no problem with my pass rules. I failed to realize that the match rules for the NAT were affecting the packet prior to the pass rules (duh) and after translation I wasn't seeing the output in the log because I was logging for only the addresses of the internal interfaces. What I found _IS_ the problem is that my match rules for NAT are failing to match every time. They are as follows: match out on $ext_if_1 from (vether0) nat-to ($ext_if_1) match out on $ext_if_2 from (vether1) nat-to ($ext_if_2) What I'm seeing by logging the two external interfaces is the result of: $ traceroute -s 172.16.0.1 -n google.com (172.16.0.1 is the IP for vether0) ...sometimes gets matched by the nat-to rule, which correctly shows up in tcpdump on the external interface with the source being the external interface's IP address. The result of this command of course gets the expected traceroute replies. The problem is, when running the exact same command over and over, is that half the time I'm seeing the traceroute requests going out on the external interface with the source being 172.16.0.1. This of course gets no replies because the NAT isn't happening. Any clues as to why my match rules work only half the time?
