"Disable NAT Reflection" versus "smtp 550 5.7.1 Unable to relay" - SOLVED

Gob · Aug 4, 2010, 8:44 PM

Here are the details of my pfSense which also experienced the same issue.

PfSense 1.2.3-RC1

Interfaces:
LAN
WAN
DMZ
WAN2
BRIDGE (to WAN2)

It is pretty much a standard setup with LAN, WAN and DMZ. We have a second WAN (WAN2) for voip traffic only. The PBX is on the Bridged interface and is the only thing routed to WAN2.
Using Automatic Outbound NAT.
There is a web server in the DMZ.
We have a default deny all rule on the LAN interface, so all outbound traffic on the LAN has specific allow rules.
There is a port (80) forwarding rule on the WAN interface with a destination of a Proxy Arp Virtual IP pointing to the web server in the DMZ.
The Outbound SMTP rule on the LAN interface has the following setting:
Protocol TCP
Source *
Src Port *
Destination *
Dst Port 25
Gateway *

When NAT reflection is enabled to allow us to access the web server through the Virtual IP, our outbound SMTP is blocked.

Hope this helps.
Gordon

Wrd2ThaWise · Aug 4, 2010, 9:09 PM

@Gob:

I had the exact same issue with outbound smtp when using Nat reflection.
I ended up disabling reflection and using split dns by adding the webserver host to the dns forwarder on Pfsense pointing to the private ip instead of the public ip.

Gob, I looked into what you recommended above (split-dns) but when I read the following article:

http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

It states:

"In order for this to work using the DNS forwarder in pfSense, your clients will need to have the IP Address of the pfSense router as their primary DNS server. "

I would not be able to change the primary DNS on our clients to point to pfsense because our primary DNS is our Active Directory controller. Your thoughts?

Wrd2ThaWise · Aug 4, 2010, 9:14 PM

@Efonne:

By the way, there is a workaround for that on 2.0 to prevent it from happening by accident, besides that it has more options there for external address anyway (now labeled destination address in 2.0).

Efonne, base on what you said above, do you think Version 2.0 would benefit me and remedy my situation?

To all, I really appreciate your thoughts and assistance. The various posts speak a testament to how popular PFSense is becoming. Thanks for supporting the new guy! ;D

Gob · Aug 4, 2010, 9:23 PM

You're right, you do need to point to your Active Directory DNS for your clients. That is how my clients are set up. However you can then put a DNS forwarder on your AD DNS server so that when it needs to look up an address not on your active directory it will use the pfSense DNS service.

You can then use the pfSense dns service to spoof external website addresses, so you put in an entry for your website on your web server but point it to the internal IP instead of the public IP.

Another way is to use your AD DNS server and create a DNS zone for the website with a www (A) record pointing to the internal IP.

Hope that makes sense?

Wrd2ThaWise · Aug 4, 2010, 9:24 PM

I don't know about you guys, but I am a visual person so I thought this may help (see attached). Here are my current NAT and firewall rules. Using the screens you see attached, I am experiencing the problem initially described by my first post.

danswartz · Aug 4, 2010, 10:42 PM

I wasn't aware of efonne's point that if you say 'any' instead of the WAN IP, it will redirect any outbound for that port. Based on your posted port forward, that is your problem. You are doing http to the ext ip, so why not smtp?

Wrd2ThaWise · Aug 5, 2010, 12:19 AM

SOLVED!

Dans,

As soon as I changed my SMTP NAT rule from "any" to "interface address" it started working fine with "Disable NAT Reflection" UNCHECKED.

Now I can send email outbound AND we can hit our company website from both the LAN and WAN.

THANKS A TON GUYS! It is really appreciated!

I must confess, I thought NAT only dealt with traffic coming in and not dealing with anything leaving our network - but hey it's fixed so I'm happy! ;D

danswartz · Aug 5, 2010, 2:00 AM

Cool!

Efonnes · Aug 5, 2010, 3:46 AM

I added the workaround in 2.0 for exactly this reason. It is something that many users do not expect to happen. (but you can prevent it if you know about it) The same thing can also happen if it somehow ends up using 0.0.0.0 for the address. I added a check for that one a few hours ago to disable reflection on such port forwards.

Wrd2ThaWise · Aug 5, 2010, 4:04 PM

Thanks Efonne! That's the great thing about open source projects, the product can get continuously improved based off of community feedback.