My problem: reply packets to inbound NAT’d connection are being sent back out the wrong interface, and being rejected as bogons by the next-hop router.
The setup… OPT1(OPT1) -> vlan0 -> 192.139.69.168 (/28) WAN -> vlan1 -> 67.226.137.177 (/29) LAN -> vlan2 -> 192.168.232.1 (/24) OPT2(OPT2) -> vlan3 -> 192.168.233.1 (/24) Virtual CARP IPs are set up on WAN, for 64.226.137.178/32 & .179/32. (Using two different VHID groups, don’t know if that makes any difference.) 1:1 NAT configured on WAN:67.226.137.179/32==192.168.232.201/32 (my mail server). There’s a firewall rule allowing inbound TCP:25 from * to 192.168.232.201. A static route is defined on OPT1 for 130.179.0.0/16 via my next-hop; they’re actually another BGP hop away from me. (I was using BGPd, but it just doesn’t work for me so back to static routes for now…) *Outbound* connections from my mail server to mail servers in 130.179.0.0/16 work just fine – they get NAT’d out the OPT1 interface correctly. *Inbound* connections from mail servers in 130.179.0.0/16, however do *not* succeed – they time out. Tcpdump(1) reveals why, the return packets are leaving via vlan0 (OPT1) instead of vlan1 (WAN). Interesting to note that they appear to have the correct source IP, but of course my next-hop router is rejecting these as bogons. This trace was limited to the mail server for cs.umanitoba.ca, one of the affected domains. This is what happens when it attempts to make a connection to my public MX (67.226.137.178) on vlan1 (WAN). # tcpdump -vvv -i vlan0 host 130.179.28.45 14:41:29.906725 IP (tos 0x0, ttl 127, id 38600, offset 0, flags [none], proto TCP (6), length 60) static-67-226-137-178.ptr.terago.net.smtp > palladium.cs.umanitoba.ca.32988: S, cksum 0x9eea (correct), 1485915749:1485915749(0) ack 101392658 win 8192 <mss 1460,nop,wscale 8,sackOK,timestamp 100653585 886751387> 14:41:32.900002 IP (tos 0x0, ttl 127, id 48922, offset 0, flags [none], proto TCP (6), length 60) static-67-226-137-178.ptr.terago.net.smtp > palladium.cs.umanitoba.ca.32988: S, cksum 0x9dbf (correct), 1485915749:1485915749(0) ack 101392658 win 8192 <mss 1460,nop,wscale 8,sackOK,timestamp 100653884 886751387> 14:41:38.895122 IP (tos 0x0, ttl 127, id 59241, offset 0, flags [none], proto TCP (6), length 56) static-67-226-137-178.ptr.terago.net.smtp > palladium.cs.umanitoba.ca.32988: S, cksum 0xcf76 (correct), 1485915749:1485915749(0) ack 101392658 win 65535 <mss 1460,sackOK,timestamp 100654484 886751387> 14:41:50.904802 IP (tos 0x0, ttl 127, id 16983, offset 0, flags [none], proto TCP (6), length 40) static-67-226-137-178.ptr.terago.net.smtp > palladium.cs.umanitoba.ca.32988: R, cksum 0xfc61 (correct), 1485915750:1485915750(0) win 0 Have I missed something in my configuration? Is this configuration so obscure it’s never been tested before? Until I get BGP route injection working properly, this “only” affects about 8 organizations I deal with… I can manually work around it by adding /32 static routes to their mail servers pointing back out vlan1 (WAN), but obviously that approach doesn’t scale (and I have to know in advance their outbound mail relay’s IP address!). Any assistance appreciated! -Adam Thompson Chief Technical Architect, C3A Inc. [email protected]<mailto:[email protected]> (204) 272-9628 / fax: (204) 272-8291
