NAT negation

Why do you want to do it in SNAT/DNAT when packet filter is designed for that sort of thing eg create group network lists that specifically allow a group of networks or create a packet filter that explicitly drops an address or range and put it at the top of the filter list.

DNAT/SNAT have no effect on the proxy traffic, so you would have to include the address in the blacklist for the proxy profile.

Ian M[[[:)]]][[[:)]]][[[:)]]]

Hi Ian

I probably missing some private conversations from you 2
or did you not understand Oxiel's question the same way as I ?

I would do some thing similar to his question:

We would like to redirect Mail-Traffic which is not coming from our internal Mailserver to our external Mail-GW which will do Mailscanning.

this would look like for normal iptables:

DNAT       tcp  --  eth0   *      !192.168.50.9         !192.168.0.0/16         tcp dpt:25 to:192.168.90.10:25

defined by
internal Mail Server:   192.168.50.9
external Mail Server:   192.168.90.10
internal Network: 192.168.0.0/16
external Network: !192.168.0.0/16

how would you or some body else solve this problem (using the ASTARO GUI)?

Both mailservers are on the same /16 network, so you don't need to worry about the firewall if they are talking to each other.

So, you just need to NAT or use the SMTP proxy on Astaro to handle all incoming mail from outside.

Barry

There are clients (out of different C-Class Networks) talking to the mailservers and not mailservers Talking to each other.
We are only talking about outgoing Mails at the Moment.

The internal Network defined by 192.168.0.0/16 has been subnetted in different C-Class and lower networks.

Client 192.168.51.2/24 tries to talk to external Mailserver 64.233.163.27, we would like this to be redirected to our outbound Mailserver 192.168.90.10

if Client 192.168.51.2/24 tries to talk to our internal Mailserver 192.168.90.10, no NAT should be done.

out internal Mailserver 192.168.50.9/24 tries to talk to external Mailserver 64.233.163.27, we would like this to go direct without redirection.

We would not like to use the SMTP proxy on the astaro (the Astaro-Firewall should only do Firewall in this part. setup).


Nessi

We would not like to use the SMTP proxy on the astaro (the Astaro-Firewall should only do Firewall in this part. setup).

You ought to reconsider using the Astaro mail proxy. Astaro uses Exim, which is a very competent SMTP mail router. For more info about Exim, check the URLs below:

http://www.exim.org/

http://en.wikipedia.org/wiki/Exim

You ought to reconsider using the Astaro mail proxy. Astaro uses Exim, which is a very competent SMTP mail router. For more info about Exim, check the URLs below:

http://www.exim.org/

http://en.wikipedia.org/wiki/Exim

although i agree that the astaro smtp proxy is good, i don't think you get the point he is tryng to make.

i am having the very same issue with snat natting my traffic to remote vpn subnets as well. there should be an exclude or negate command to prevent this from happening. i am forced to use masquerading for the time being until this is resolved. unfortunately masquerade is too limiting for me.

i hope they resolve this issue soon.

I'm currently working this with support but anyone here is more than welcome to help out.  I'm stuck at the moment.

>>

ISSUE:
Email servers on the Internet are usually configured to do a reverse DNS lookup on any host that attempts to relay a mail message using the SMTP protocol.  This is normal and intended.  We had a S/NAT and a D/NAT rule in place on the Astaro that mapped our Exchange server's internal IP address (10.10.10.2) to an external IP address (209.34.254.79).  We have this rule in place because we need to follow RFC and make sure that the DNS records for forward and reverse match the IP address of the server sending mail outbound.  Once we put this rule in place, we lost the ability to communicate from the Exchange server to hosts that are located in another of our sites in NY over an IPSec VPN tunnel.

I am trying to find a way to get the address NAT'ing done so that when our Exchange server relays mail on an external host (e.g. sending mail to me@yahoo.com) the IP address is translated as a source of 209.34.254.79, while not NAT'ing the address across a VPN tunnel.  I don't know that the address is NAT'd across the tunnel but I'm assuming this because disabling the NAT rule clears up the issue.

Here are some information points:

ORIGINAL S/NAT RULE: Tried this and the NAT'ing to the outside world works but it killed traffic from this host to hosts across the VPN tunnel
Traffic Source: 10.10.10.2
Traffic Service: Any
Traffic Destination: Any
NAT mode: SNAT
Source: 209.34.254.79
Source Service: Any

* I have other hosts setup for NAT this way currently and they cannot ping across the tunnel.  So they are broken too but not as critical as our E-mail system is.

ALTERNATIVE RULE: Doesn't work.  Traffic flows across the tunnel fine but traffic to external hosts (e.g. that Yahoo mail server) is not NAT'd to 209.34.254.79
Traffic Source: 10.10.10.2
Traffic Service: Any
Traffic Destination: Any
NAT mode: SNAT
Source: 209.34.254.64/26 (WAN-1 Network)
Source Service: Any

ANOTHER ALTERNATIVE RULE: Have not turned this one on because I don't know if it will break things, fix the problem or what.
NOTE: I've created a Network Group that contains all "local subnets" (e.g. our VLANs, subnets on the other side of our IPSec tunnels, etc.) and called the Network Group Internal Subnets.
Traffic Source: Internal Subnets
Traffic Service: Any
Traffic Destination: Internal Subnets
NAT mode: SNAT
Source: (left the source null here)
Source Service: Any

SMTP PROXY Stuff:
We can't use the SMTP proxy because it cannot make the source address (external) different on a per-domain basis.  We host mail for multiple domains and we need to be able to have mail_server_1 NAT'd outside to public_address_1 and we need to have mail_server_2 NAT'd outside to public_address_2.  These two servers would be sending mail as different domains.

We do use the Inbound SMTP Proxy and it seems to be working fine right now.  It's smart enough to send mail to separate internal SMTP servers based on the domain of the recipient.

SUMMARY:
We desperately need to get this fixed as some portion of mail we send (and mail that our hosted customers send) are getting bounced for breaking RFC.  This firewall is production so whatever we decide to do needs to be based in fact and on deep knowledge of the way the Astaro works.

We have multiple internal hosts that are being impacted by this issue and we have customers that are being impacted as well.

hspcd, here is what you need to do.

Some definitions:
SMTP-Server-Ext - 209.34.254.79
SMTP-Server-Int - 10.10.10.2
SMTP-No-Nat-Nets - Network group of all your VPNed networks or possibly also other LANs

NAT Rules:
SMTP-Server-10 in - SRC Any - DST SMTP-Server-Ext - Translate DST  SMTP-Server-Int
SMTP-Server-50 no nat - SRC SMTP-Server-Int - DST SMTP-No-Nat-Nets - Translate SRC SMTP-Server-Int
SMTP-Server-90 out - SRC SMTP-Server-Int - DST Any - Translate SRC SMTP-Server-Ext

Notes:
To avoid NATting to certain subnets, add them to the No-Nat-Nets group.
See how the rules are numbered so that we can order the rules manually since Astaro doesn't let you reorder the NAT rules and the get ordered alphabetically by default. You need to the no nat rule to take effect before the out rule.

Drees, thanks a ton.  This is working perfectly!

Cheers

Glad I could help. [:)]

-Dave