SRX persistent NAT

[Jhattaak]

Hi Experts,

I have configured the following persistent NAT on SRX 210:

source {

    pool POOL {

        address {

            172.31.100.20/32;

            172.31.200.20/32;

        }

        port no-translation;

    }

    port-randomization disable;

    rule-set N1 {

        from zone Internet;

        to interface vlan.2;

        rule rule1 {

            match {

                source-address 0.0.0.0/0;

            }

            then {

                source-nat {

                    pool {

                        POOL;

                        persistent-nat {

                            permit target-host;

                        }

                    }                   

                }

            }

        }

    }

}

proxy-arp {

    interface vlan.2 {

        address {

            172.31.100.20/32;

        }

    }

}

However, when I initiate pings, the pings FAIL. At the same time, if I initiate HTTP traffic for the same destination, it works. It seems like the above translation fails for ICMP and is successful for TCP 80. 

The pings do not work even after a persistent NAT entry is made by initiating HTTP.

I have attached  traces from both PINg (failed) and TCP 80 (successful).

When I remove the persistent-nat configuration, I am able to ping successfully.

Is there a known issue with pings and persistent-nat? Is this an expected behaviour?

Inputs would be highly appreciated.

Thanks,

MJ 

[Jhattaak]

Also, I tried to test Persistent NAT behaviour in the following way:

10.0.1.99 ------HTTP----------> 172.31.100.60(SRX)

Source gets translated persistently to 172.31.100.20

So I have the following persistent NAT entry:

root# run show security nat source persistent-nat-table all    

     Internal                Reflective          Source     Type             Left_time/  Curr_Sess_Num/  Source

 In_IP          In_Port Ref_IP          Ref_Port NAT Pool                    Conf_time   Max_Sess_Num    NAT Rule

10.1.0.99       1343    172.any-remote-host     -/300      1/30          rule1   

Now, in order to check flow in the other direction, I initiate telnet on port 3389 from the SRX (172.31.100.60) to 172.31.100.20.

I get a connection timed-out.

I've added the correct security policy. RDP is allowed on the computer, I can telnet to 10.1.0.99 on port 3389 successfully.

In the traces, I see the following error:

Output ifp is self but it is not for self packet and the IP(172.31.100.20) is in Source NAT pool, we don't create the session.
packet dropped, self ip in src nat pool.

Traces are attached

Thanks!

[SomeITGuy]

You have posted your nat and your arp, but not the security policies....

In your security policy are you creating the rules on the IP prior to translation?

On the port 80 traffic that was succesful outbound is it hitting the rule you are expecting it to? Or is it being allowed out through a more general existing rule since outbound port 80 rules would be fairly common?

[JunOS_Fan]

Hi ,

From the following output, it seems that you are using "any-remote-host" option in persistent nat . In this scenario , if you want to check the traffic in the other direction (with out any security policy in place ), we need to have "address-mapping " statement .

root# run show security nat source persistent-nat-table all    

     Internal                Reflective          Source     Type             Left_time/  Curr_Sess_Num/  Source

 In_IP          In_Port Ref_IP          Ref_Port NAT Pool                    Conf_time   Max_Sess_Num    NAT Rule

10.1.0.99       1343    172.any-remote-host     -/300      1/30          rule1   

Here's my lab output -  With out address-mapping statement , none of these two examples  worked.

[edit]
root@SRX# show | display set | no-more 
set version 11.2R1.10
set system host-name SRX
set system root-authentication encrypted-password "$1$WzZTmJ.v$yTLc82F4znVPoMYxflgfx1"
set interfaces ge-0/0/0 unit 0 family inet address 10.0.1.1/24
set interfaces ge-0/0/1 unit 0 family inet address 172.31.100.1/24
set security flow traceoptions file pnat
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter 1 source-prefix 172.31.100.60/32
set security flow traceoptions packet-filter 1 destination-prefix 172.31.100.20/32
set security flow traceoptions packet-filter 2 source-prefix 10.0.1.99/32
set security flow traceoptions packet-filter 2 destination-prefix 172.31.100.60/32
set security nat source pool POOL address 172.31.100.20/32
set security nat source pool POOL address 172.31.200.20/32
set security nat source pool POOL port no-translation
set security nat source port-randomization disable
set security nat source rule-set N1 from zone internet
set security nat source rule-set N1 to interface ge-0/0/1.0
set security nat source rule-set N1 rule 1 match source-address 0.0.0.0/0
set security nat source rule-set N1 rule 1 then source-nat pool POOL
set security nat source rule-set N1 rule 1 then source-nat pool persistent-nat permit any-remote-host
set security nat source rule-set N1 rule 1 then source-nat pool persistent-nat address-mapping
set security nat proxy-arp interface ge-0/0/1.0 address 172.31.100.20/32
set security policies from-zone internet to-zone dmz policy test match source-address any
set security policies from-zone internet to-zone dmz policy test match destination-address any
set security policies from-zone internet to-zone dmz policy test match application any
set security policies from-zone internet to-zone dmz policy test then permit
set security zones security-zone internet interfaces ge-0/0/0.0
set security zones security-zone dmz interfaces ge-0/0/1.0

[edit]
root@SRX# run show route | no-more 

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24        *[Direct/0] 00:35:41
                    > via ge-0/0/0.0
10.0.1.1/32        *[Local/0] 00:39:34
                      Local via ge-0/0/0.0
172.31.100.0/24    *[Direct/0] 00:01:58
                    > via ge-0/0/1.0
172.31.100.1/32    *[Local/0] 00:39:34
                      Local via ge-0/0/1.0
172.31.100.20/32   *[Static/1] 00:15:51
                      Discard

 Flow trace output for the ICMP traffic initiated from 172.31.100.60 to 172.31.100.20 (reflective address) - note that there is no security polic from zone dmz(ge-0/0/1) to internet (ge-0/0/0.0) and how the policy search is bypassed for persistent-nat. It works the same way for other protocols like TCP also.

[edit security flow]
root@SRX# 
root@SRX# run show security flow session    
root@SRX# run show security nat source persistent-nat-table all    
     Internal                        Reflective                  Source     Type             Left_time/  Curr_Sess_Num/  Source
 In_IP          In_Port I_Proto Ref_IP          Ref_Port R_Proto NAT Pool                    Conf_time   Max_Sess_Num    NAT Rule
10.0.1.99       *       *      172.31.200.20   *         *        POOL       any-remote-host   298/300      0/30          1        

[edit security flow]
root@SRX# run monitor start pnat
root@SRX# run monitor start pnat    

[edit security flow]
root@SRX# 
*** pnat ***
May  8 04:36:28 04:36:27.1175488:CID-0:RT:<172.31.100.60/62161->172.31.200.20/21;6> matched filter 1:

May  8 04:36:28 04:36:27.1175488:CID-0:RT:packet [60] ipid = 13460, @423fc09e

May  8 04:36:28 04:36:27.1175488:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423fbe80, rtbl_idx = 0

May  8 04:36:28 04:36:27.1175488:CID-0:RT: flow process pak fast ifl 69 in_ifp ge-0/0/1.0

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  ge-0/0/1.0:172.31.100.60/62161->172.31.200.20/21, tcp, flag 2 syn

May  8 04:36:28 04:36:27.1175488:CID-0:RT: find flow: table 0x4a056998, hash 8021(0xffff), sa 172.31.100.60, da 172.31.200.20, sp 62161, dp 21, proto 6, tok 9 

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  flow_first_create_session

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/1.0>, out <N/A> dst_adr 172.31.200.20, sp 62161, dp 21

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  chose interface ge-0/0/1.0 as incoming nat if.

May  8 04:36:28 04:36:27.1175488:CID-0:RT:persistent-nat outgoing policy search from zone internet-> zone dmz

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  app 0, timeout 1800s, curr ageout 20s

May  8 04:36:28 04:36:27.1175488:CID-0:RT:flow_first_rule_dst_xlate: packet 172.31.100.60->172.31.200.20 nsp2 0.0.0.0->10.0.1.99.

May  8 04:36:28 04:36:27.1175488:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 172.31.100.60, x_dst_ip 10.0.1.99, in ifp ge-0/0/1.0, out ifp N/A sp 62161, dp 21, ip_proto 6, tos 0

May  8 04:36:28 04:36:27.1175488:CID-0:RT:Doing DESTINATION addr route-lookup

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  routed (x_dst_ip 10.0.1.99) from dmz (ge-0/0/1.0 in 0) to ge-0/0/0.0, Next-hop: 10.0.1.99

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  flow_first_policy_search: bypassed by persistent-nat

May  8 04:36:28 04:36:27.1175488:CID-0:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

May  8 04:36:28 04:36:27.1175488:CID-0:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: True.

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  dip id = 0/0, 172.31.100.60/62161->172.31.100.60/62161 protocol 0

May  8 04:36:28 04:36:27.1175488:CID-0:RT:  choose interface ge-0/0/0.0 as outgoing phy if

another example  for ICMP Traffic  (for 172.31.100.20) -

May  8 05:34:00 05:34:00.763981:CID-0:RT:<172.31.100.60/35->172.31.100.20/1;1> matched filter 1:

May  8 05:34:00 05:34:00.763981:CID-0:RT:packet [60] ipid = 13940, @42400d1e

May  8 05:34:00 05:34:00.763981:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x42400b00, rtbl_idx = 0

May  8 05:34:00 05:34:00.763981:CID-0:RT: flow process pak fast ifl 69 in_ifp ge-0/0/1.0

May  8 05:34:00 05:34:00.763981:CID-0:RT:  ge-0/0/1.0:172.31.100.60->172.31.100.20, icmp, (8/0)

May  8 05:34:00 05:34:00.763981:CID-0:RT: find flow: table 0x4a056998, hash 19976(0xffff), sa 172.31.100.60, da 172.31.100.20, sp 35, dp 1, proto 1, tok 9 

May  8 05:34:00 05:34:00.763981:CID-0:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0

May  8 05:34:00 05:34:00.763981:CID-0:RT:  flow_first_create_session

May  8 05:34:00 05:34:00.763981:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/1.0>, out <N/A> dst_adr 172.31.100.20, sp 35, dp 1

May  8 05:34:00 05:34:00.763981:CID-0:RT:  chose interface ge-0/0/1.0 as incoming nat if.

May  8 05:34:00 05:34:00.763981:CID-0:RT:persistent-nat outgoing policy search from zone internet-> zone dmz

May  8 05:34:00 05:34:00.763981:CID-0:RT:  app 0, timeout 60s, curr ageout 60s

May  8 05:34:00 05:34:00.763981:CID-0:RT:flow_first_rule_dst_xlate: packet 172.31.100.60->172.31.100.20 nsp2 0.0.0.0->10.0.1.99.

May  8 05:34:00 05:34:00.763981:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 172.31.100.60, x_dst_ip 10.0.1.99, in ifp ge-0/0/1.0, out ifp N/A sp 35, dp 1, ip_proto 1, tos 0

May  8 05:34:00 05:34:00.763981:CID-0:RT:Doing DESTINATION addr route-lookup

May  8 05:34:00 05:34:00.763981:CID-0:RT:  routed (x_dst_ip 10.0.1.99) from dmz (ge-0/0/1.0 in 0) to ge-0/0/0.0, Next-hop: 10.0.1.99

May  8 05:34:00 05:34:00.763981:CID-0:RT:  flow_first_policy_search: bypassed by persistent-nat

May  8 05:34:00 05:34:00.763981:CID-0:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

May  8 05:34:00 05:34:00.763981:CID-0:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: True.

May  8 05:34:00 05:34:00.763981:CID-0:RT:  dip id = 0/0, 172.31.100.60/35->172.31.100.60/35 protocol 0

May  8 05:34:00 05:34:00.763981:CID-0:RT:  choose interface ge-0/0/0.0 as outgoing phy if

[JunOS_Fan]

One observation related to ICMP is that -

1. with any-remote-host + no address-mapping , ICMP traffic is not triggering persistnet nat binding. Only TCP trafic triggers persistent nat .  I mean when I initiate ICMP traffic from 10.1.0.99 ,there is no output in "show security nat source persistent-nat-table all  ".

2. with target-host option -  I am able to ping (as well as TCP traffic) successfully from 10.1.0.99 towards 172.31.100.60 but not in the reverse direction . i.e from 172.31.100.60 to the reflective address 172.31.100.20 (or 172.31.200.20) .  and we can't use address-mapping option with this .

Hope this helps . If any one had any luck with target-host option (traffic from other direction),please share.

[Jhattaak]

Thnak you for the response!

In order to simplify things, I added a permit all policy in the other direction.

[Jhattaak]

still don't understand whether this is an issue or an expected behaviour.