Hybrid Outbound NAT confusion
I'm missing something basic about how turning off NAT changes routing for a simple network setup.
Objective is to enable inbound / outbound traffic for an SMTP server at x.y.z.43. Having all other outbound traffic NAT'd through the WAN's base IP, x.y.z.42, is OK. I want to control the DNS PTR record for the SMTP traffic so that it's not
static-x-y-z-42.podunk.fios.verizon.net. SPF, DKIM, DMARC work; STARTTLS works at least where external mailhosts tolerate mismatched CNs.
Actiontec MI424WR-GEN3i (v40.21.24; latest)
NAT: x.y.z.43 <--> 192.168.20.43
A route is in place:
192.168.1.20.0/24 gw 192.168.1.2
port forwarding for 192.168.20.43 is simply:
SMTP TCP Any -> 25
pFsense (v2.4.4_2; latest stable)
0: WAN 192.168.1.2
1: LAN1 192.168.0.1
2: LAN2 192.168.20.1
3: LAN3 192.168.30.1
default gw is 192.168.1.1
With Automatic outbound NAT, this generally works. Clicking the "Hybrid NAT" option and disabling NAT for 192.168.20.0/24 allows inbound traffic through. So SMTP traffic can be received. However, outbound SMTP doesn't make it through this setup. Logging on the mailhost shows:
Apr 17 19:42:40 draco postfix/smtp: connect to alt4.gmail-smtp-in.l.google.com[188.8.131.52]:25: No route to host Apr 17 19:42:40 draco postfix/smtp: D23501C0068: email@example.com, relay=none, delay=598, delays=523/0/76/0, dsn=4.4.1, status=deferred (connect to alt4.gmail-smtp-in.l.google.com[184.108.40.206]:25: No route to host)
I suspect the issue is with the Actiontec configuration, since ping from 192.168.20.43 to 192.168.1.1 works. But, ping to external sites stops working. So I'm likely missing something basic about how dropping NAT changes what rules need to be in the Actiontec.
Guidance and schooling would be welcome.
Address translation on outbound traffic has to be handled by the edge router.
If you disable the outbound NAT for 192.168.20.0/24 on pfSense you have to add a static route for that network to the Actiontec, pointing to pfSense WAN IP, to let it know how to route back response packets.
@WhiteRabbit said in Hybrid Outbound NAT confusion:
I get that. So is the pFsense WAN IP something other than 192.168.1.2 in this setup? A static route
192.168.1.20.0/24 gw 192.168.1.2
already in place on the Actiontec.
No, that's okay. I haven't seen that.
Maybe the Actiontec doesn't allow outbound from that network, since it doesn't know it?
Outbound generally works when NAT is on . I was expecting that toggling NAT on/off wouldn't require changing the routing. So I'm missing something.
Any ideas on diagnostics? Absent any other clues, I'll focus on getting syslog'ing from the Actiontec to an internet logging server working. Log viewing capabilities in the device's web interface are useless.
When you turn on outbound NAT on pfSense, it translates any source IPs to its WAN IP. So the Actiontec only sees an IP within its own LAN network, which is his basic usage.
Do you see any blocks on the Actiontec?
However, is it basically possible on the Actiontec router to configure the outbound NAT to translate packets from the mail server to x.y.z.42?
If it is, to investigate what's going on on WAN, you'll have to check the WAN packets by a sniffer tool.
Best would be to put the Actiontec into bridge mode and have the WAN address on pfSense.
"When you turn on outbound NAT on pfSense, it translates any source IPs to its WAN IP. So the Actiontec only sees an IP within its own LAN network.... Do you see any blocks on the Actiontec?"
OK, thanks for the clue. I'm not aware of any rules on the Actiontec that block ! 192.168.1.0/24 source IPs. At least the web admin screens don't show any, though that doesn't mean they're not in play. The device does log blocking actions; it's just that the web-based viewing of the traces is useless. (So, I need th get syslog'ing up.)
OK, got it. The Actiontec actually has a set of default rules. You can't get at them, but the string "Blocked - default policy" occasionally turns up in the web view of the logging.
Awkwardly, it allows anything outbound from its immediate LAN, 192.168.1.1/24. So an SMTP server plugged directly into one of the Actiontec's ethernet ports works perfectly fine. Placing it on another internal subnet, though, puts the default stuff in play. From there, this was a downhill run. The screen shots are provided to document the details for the community.