SRX

Hi-

 

New to the forum so not sure how all this works.

Anyway, I will be replacing my older NS-25 with a Juniper SRX 220H this weekend and I had a configuration question in regards to outbound mailflow.

With the default source-Nat statement below to allow for internet traffic flow, do I need to add a static Nat entry as well to accommodate the external IP of my Exchange server. Will the Exchange server on the other end be able to accept mail if it comes from the External IP of my SRX.

rule-set inet1
       from zone trust;
       to zone untrust;

rule test {
       match destination-address 0.0.0.0/0
        }
        then source-nat  {
                          interface

Let me know if you need more info.

#JUNOS
#SRX

The statement shown will send all traffic leaving the trust zone (regardless of IP address) to addresses in the untrust zone using the IP address of the external interface. 

 

Unless your external server has a requirement that traffic be sourced from a specific IP this will work fine from a NAT perspective for outbound traffic. 

 

You of course must have a policy to allow the traffic to flow. Hope this answers your question. 

Kevin-

 

Thanks for the response. The only requirement I could think of where the traffic must be sourced to a specific IP would be the MX record itself. Would it still be able to translate to the external IP of the exchange server if it is referring to the source interface for its address translation in the source-nat statement.

 

Would a statement as such be unecessary:

 

 rule-set rs1 {
                from zone untrust;
                rule r1 {
                    match {
                        destination-address x.x.x.x (external address of exchange server);
                    }
                    then {
                        static-nat {
                            prefix {
                                x.x.x.x (internal address of exchange server);

Well, I was very careful in my wording as I don't know your complete scenario. 

 

The first scenario works fine for traffic flowing outbound to an external address using the same IP as the external IF.

 

The second scenario works when you want that fixed relationship established for both inbound and outbound traffic IP flows which is quite common for things like mail. 

Right, and I understand that every scenario is different.

 

Basically our setup works likes this, we have inbound mail pointed to one external IP and then outbound mail goes out a completely different external IP. Now would static Nat only be for when I needed both of those external IP addresses to be the same? Here is the policy I will be using as well in order to allow the outbound email flow from the internal network. Can the value for source-address be Any like the ScreenOS or does it have to be defined as specific network IP.

 

policy trust2inet {
    match {
        source-address [ LAN IP Addresses ];
        destination-address any;
        application any;
    }
    then {
        permit;
        log {
            session-close;

1. Yes, static NAT is when you want that one to one mapping bi-directional. 

 

2. Your policy can be as granular or as open as you like. You have an outbound policy shown here and frankly if you have another outbound policy for your regular (non mail) traffic then this policy is of no value unless you want a seperate policy just for logging purposes. Does that comment make sense?

 

When you consider that the Junos security architecture was based on ScreenOS in terms of zones, policies, etc it makes a lot sense. The policies are simply filters. I always try and write as few as policies as possible to accomplish my objectives.

 

The biggest difference between ScreenOS and Junos in terms of security processing is the complete de-coupling of all forms of NAT from policy. Once you really get that and seperate them in your mind it is much easier. And remembering when to you what address (pre or post NAT address wise). 

 

Knowing the packet flow and when NAT is done versus policy lookup is essential.

Kevin-

1. So if I don't need the mapping to be bi-directional then source-nat should work just fine.

2. Yes, makes sense. I was planning to use this same policy for both my internet and outbound mail.

3. Good point about the separation of Nat from policies in Junos. I was noticing that being a huge difference between policies in Screenos as opposed to Junos.

Kevin-

 

Big Kudos to you. Your breakdown of the way JunOS handles NAT really helped me to understand the logic I was missing. I did have to create a static NAT entry in order to get the mail flow working correctly and of course edit my existing security policy.

So give me a kudo on my post and I will be a happy camper 🙂

 

Seriously - glad to be of assistance to you in learning the SRX.

Forgive my ignorance, but where is the magical Kudo feature. I will be more than happy to.

nvm, figured it out. Kudos!