On Tue, Feb 28, 2006 at 11:22:48PM -0500, Yasholomew Yashinski wrote: > > I'm not sure what changed, as I haven't made any changes in the past 48 > hours that I recall other than a portupgrade, however when I got home > this afternoon my NAT was hosed. I'm using tun0 (PPPoE over hme0) on > FreeBSD 6.0 sparc64.
this wouldn't relate to your situation given the lack of changes, but any time i've had translation rules not _function_ (match/apply) and i spent an hour+ pulling my hair out to figure out why, it's because i got the bright idea to put a 'set skip on $the_iface_where_my_rdrs_are_broke_now' in there... the other one is where i forget ip.forwarding=1 and no packets even attempt to come out the other side ( different from them being not NAT'ted ), but that's not your case. > from pf.conf: > anon_gw="206.248.137.44" > nat_net="192.168.1.0/28" > tun_if="tun0" > nat on $tun_if from $nat_net to any -> $anon_gw > > # pfctl -sn > nat on tun0 inet from 192.168.1.0/28 to any -> 206.248.137.44 > rdr inet proto tcp from <spamd> to any port = smtp -> 127.0.0.1 port 8025 > > from sysctl: > net.inet.ip.forwarding: 1 > > on the firewall/gateway: > # tcpdump -i rl0 port 80 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes > 18:00:18.000470 IP 192.168.1.8.33243 > www.fark.com.http: S > 3062197018:3062197018(0) win 5840 <mss 1460,sackOK,timestamp 10515598 > 0,nop,wscale 0> > 18:00:20.998748 IP 192.168.1.8.33243 > www.fark.com.http: S > 3062197018:3062197018(0) win 5840 <mss 1460,sackOK,timestamp 10518598 > 0,nop,wscale 0> > 18:00:26.997008 IP 192.168.1.8.33243 > www.fark.com.http: S > 3062197018:3062197018(0) win 5840 <mss 1460,sackOK,timestamp 10524598 > 0,nop,wscale 0> > > # tcpdump -i tun0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes > 21:26:11.200002 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:11.255089 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 16429+ > [1au] PTR? 44.137.248.206.in-addr.arpa. (56) > 21:26:11.306036 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 16429 > 1/2/3 PTR[|domain] > 21:26:11.310112 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 58322+ > [1au] PTR? 0.0.0.0.in-addr.arpa. (49) > 21:26:11.360753 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 58322 > NXDomain* 0/1/1 (99) > 21:26:12.364075 IP mail.yashy.com > 0.0.0.0: pfsync 228 > 21:26:12.366593 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 29161+ > [1au] PTR? 22.154.248.206.in-addr.arpa. (56) > 21:26:12.418296 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 29161 > 1/2/3 PTR[|domain] > 21:26:13.421003 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:14.425044 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:15.429063 IP mail.yashy.com > 0.0.0.0: pfsync 228 > 21:26:16.467022 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:17.712070 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:19.074030 IP mail.yashy.com > 0.0.0.0: pfsync 452 > 21:26:20.433105 IP mail.yashy.com > 0.0.0.0: pfsync 228 > > So I can see the requests going out on rl0 (but getting no reply), but > it's not showing up on tun0/hme0 at all. > I'm running bind on the fw/gw machine as well, so that is why the client > is able to resolve www.fark.com (which makes me wonder why it's querying > dns.pppoe.ca as I'm not trying to resolve anything that shouldn't be in > the dns cache already..). > Are all of these pfsync logs to 0.0.0.0 normal? if you have no pfsync interfaces '<UP>'/configured, i would think not. i tried one and it doesn't send pfsync packets until i give it a 'syncdev'. i don't know if things are different at all in freebsd, but using/enabling pfsync is definately not compulsory. i'd guess/hope it wasn't much different there. > On this linux client: > $ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt > Iface > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > 0.0.0.0 192.168.1.10 0.0.0.0 UG 0 0 0 > eth0 does it matter in your case that the netmask is a /24 there but a /28 in your nat line above? nah.. probably not if the linux host is .10 or .8? that 'gateway 0.0.0.0' thing confuses the hell out of me. i see it on the machines at work and always need the linux guys to explain to me the output of the routing table while i bitch about route(8) not working or making sense to me :( > From the client machines, I'm getting an IP via dhcpd from the fw/gw. I > can ping the fw/gw as well as ssh to it etc. If I ssh to the fw/gw, I > can get out from it no problem. I just can't get through the fw/gw from > the client machines. this might be slightly crackassed, but if you throw up a reject route on the firewall, do lan clients get an appropriate unreachable when trying to talk to it? eg: [firewall] $ sudo route add -host 86.75.30.9 $default_gateway -reject when i do something similar, and 'ping -v' from another obsd host on the lan, i see the '36 bytes from blah (IP): Destination Host Unreachable' come back -- at least implies to me that blah (IP) had an intent to try to route the packet ( eg, if i *do* set forwarding=0, i get no more unreachables with my current config ). testing wise, maybe that would help shed light on what is/isn't working. -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
