SRX

I am new to the SRX and I am having problems routing between vlans and I hope someone can help.

This is a picture of my configuration:

I am trying to route traffic between vlan.10 and vlan.800 (between zones trust and untrust.

from the 192.168.100.2.  I cannot ping any address on the 10.1.8.0 network and from 10.1.8.71.  Also I cannot ping any address on the 192.168.100.0 network.  From the SRX240 I can ping everything.

Here is the configuration that I am using:

root@dpr-fw> show configuration 
## Last commit: 2017-01-14 00:05:23 UTC by root
version 12.3X48-D35.7;
system {
    host-name dpr-fw;
    root-authentication {
        encrypted-password "."; ## SECRET-DATA
    }
    name-server {
        208.67.222.222;
        208.67.220.220;
    }
    services {
        ssh;
        xnm-clear-text;
        web-management {
            http {
                interface vlan.300;
            }
            https {
                system-generated-certificate;
                interface vlan.300;
            }
        }
    }                                   
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any critical;
            authorization info;
        }
        file interactive-commands {
            interactive-commands error;
        }
    }
    max-configurations-on-flash 5;
    max-configuration-rollbacks 5;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
}
security {
    screen {                            
        ids-option untrust-screen {
            icmp {
                ping-death;
            }
            ip {
                source-route-option;
                tear-drop;
            }
            tcp {
                syn-flood {
                    alarm-threshold 1024;
                    attack-threshold 200;
                    source-threshold 1024;
                    destination-threshold 2048;
                    timeout 20;
                }
                land;
            }
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {   
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone trust {
            policy untrust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone trust { 
            policy trust-to-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        default-policy {
            permit-all;
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;                
                }
            }
            interfaces {
                vlan.800 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
            }
        }
        security-zone untrust {
            inactive: screen untrust-screen;
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;                
                }
            }
            interfaces {
                vlan.10 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
            }
        }
        security-zone fw-manage {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }                       
            }
            interfaces {
                vlan.300;
            }
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members utility;
                }
            }
        }
    }
    ge-0/0/4 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan-untrust;
                }
            }
        }
    }
    ge-0/0/5 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan-untrust;
                }
            }
        }
    }
    ge-0/0/8 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan-trust;
                }
            }
        }                               
    }
    vlan {
        unit 10 {
            family inet {
                address 192.168.100.88/24;
            }
        }
        unit 300 {
            family inet {
                address 10.1.3.88/24;
            }
        }
        unit 800 {
            family inet {
                address 10.1.8.88/24;
            }
        }
    }
}
protocols {
    igmp {
        interface all;
    }                                   
    stp;
    igmp-snooping {
        vlan all;
    }
}
vlans {
    utility {
        vlan-id 300;
        l3-interface vlan.300;
    }
    vlan-trust {
        vlan-id 800;
        l3-interface vlan.800;
    }
    vlan-untrust {
        vlan-id 10;
        l3-interface vlan.10;
    }
}

If anybody can help me figure out what is wrong I would appreciate it.

Do a flow traceoption to see how the traffic is being handled.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16110

Hi Folks,

This example shows how to set up a new zone and add three application servers to that zone. Then you provide communication between a host (PC) in the trust zone to the servers in the newly created zone and also facilitate communication between two servers within the zone.

To meet this requirement, you need an interzone security policy to allow traffic between two zones and an intrazone policy to allow traffic between servers within a zone.

http://www.juniper.net/documentation/en_US/junos15.1x49/topics/example/security-srx-device-zone-and-policy-configuring.html

Are all of your hosts using x.x.x.88 as their gateways?

That was the problem. I had the gateway on each box pointed to the interface as the next-hop.  Once I changed the routing table to point the next-hop to the routable vlan interface on the SRX I could ping in both directions.  That was a stupid mistake!  Thanks so much for the help!

👍

Hi Folks,

I'm fairly new with Juniper devices and I'm having an issue with interVLAN routing on SRX650 (Cluster)

I've already read few topics regarding routing issues on SRX devices but it seems to be not working as expected.

I'm almost sure there is a silly mistake in my configuration

Background:

We have a cluter of SRX650's connected with two uplinks back to cisco CAT3850.
JUNOS Software Release [12.1X44-D35.5]

The following interfaces are merged into the redundant interface reth2

set interfaces ge-2/0/2 gigether-options redundant-parent reth2
set interfaces ge-2/0/6 gigether-options redundant-parent reth2
set interfaces ge-11/0/2 gigether-options redundant-parent reth2
set interfaces ge-11/0/6 gigether-options redundant-parent reth2

On the interface reth2 we have the following configuration:

set interfaces reth2 vlan-tagging
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 3 vlan-id 3
set interfaces reth2 unit 3 family inet address 10.32.1.254/24
set interfaces reth2 unit 43 vlan-id 43
set interfaces reth2 unit 43 family inet address 10.32.43.254/24

.

.

.
set interfaces reth2 unit 222 vlan-id 222
set interfaces reth2 unit 222 family inet address 10.32.222.254/24

Problem description

ex.

From the PC A (V43: 10.32.43.123) I can't ping the PC B (v222: 10.32.222.35)

FYI I can ping both devices within their subnets so there is no issue with icmp.

pzatorski@srx> ping 10.32.43.123 source 10.32.222.254
PING 10.32.43.123 (10.32.43.123): 56 data bytes
^C
--- 10.32.43.123 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

The gateways are pingable

pzatorski@srx> ping 10.32.43.254 source 10.32.222.254
PING 10.32.43.254 (10.32.43.254): 56 data bytes
64 bytes from 10.32.43.254: icmp_seq=0 ttl=64 time=0.972 ms

pzatorski@srx> show route | match 10.32.222.
10.32.222.0/24     *[Direct/0] 1d 10:36:33
10.32.222.254/32   *[Local/0] 1d 10:36:33

{primary:node0}
pzatorski@srx> show route | match 10.32.43.
10.32.43.0/24      *[Direct/0] 1d 10:36:36
10.32.43.254/32    *[Local/0] 1d 10:36:36

pzatorski@srx> show arp | match 10.32.43.123
00:50:56:82:59:e4 10.32.43.123    02v00114 veeam reth2.43            none

{primary:node0}
pzatorski@srx> show arp | match 10.32.222.35
00:50:56:88:00:1c 10.32.222.35    02v00107 reth2.222           none

reth2.43                up    up   inet     10.32.43.254/24

reth2.222                up    up   inet     10.32.222.254/24

from the security site I've attached zones to both interfaces (reth2.43 and .222)

set security zones security-zone management-v43 interfaces reth2.43 host-inbound-traffic system-services all
set security zones security-zone management-v43 interfaces reth2.43 host-inbound-traffic protocols all

set security zones security-zone admin-v222 interfaces reth2.222 host-inbound-traffic system-services all
set security zones security-zone admin-v222 interfaces reth2.222 host-inbound-traffic protocols all

I've configured bi-directional policies as well:

set security policies from-zone management-v43 to-zone admin-v222 policy 4 match source-address any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 match destination-address any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 match application any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 then permit
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match source-address any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match destination-address any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match application any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 then permit

On the switch site the uplink interfaces are set to mode trunk.

your help is greatly appreciated!

Many thanks!

Patryk

Hi Patryk,

Are uplinks on c3850 configured as etherchannels?

Hi Wdudys,

They are not configured as etherchannels

Thx,

On cisco side ports connected to ge-2/0/2, ge-2/0/6 should be configured as first etherchannel and
ports connected to ge-11/0/2, ge-11/0/6 as a second etherchannel.

Please correct the configuration and let us know if it helped.

It is recommended to use LACP

#set interfaces reth2 redundant-ether-options lacp active|passive
#set interfaces reth2 redundant-ether-options lacp periodic fast|slow

You can then verify with

>show lacp interfaces

Regards, Wojtek

Dear Wojtek,

Apologies for late reply.

I've configured the LACP as you suggested meaning:

CAT3850

Gi1/0/1   SRX_2/0/2          connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/3   SRX_11/0/2         connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi2/0/1   SRX_2/0/6          connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi2/0/3   SRX_11/0/6         connected    trunk      a-full a-1000 10/100/1000BaseTX
Po5       LACP to SRX1       connected    trunk      a-full a-1000
Po6       LACP to SRX2       connected    trunk      a-full a-1000

Where Gi1/0/1 and Gi2/0/1 are in Po5

Gi1/0/3 and Gi2/0/3 are in Po6

SRX

Aggregated interface: reth2
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-11/0/2      Actor    No    No   Yes  Yes  Yes   Yes     Slow   Passive
      ge-11/0/2    Partner    No    No   Yes  Yes  Yes   Yes     Slow    Active
      ge-11/0/6      Actor    No    No   Yes  Yes  Yes   Yes     Slow   Passive
      ge-11/0/6    Partner    No    No   Yes  Yes  Yes   Yes     Slow    Active
      ge-2/0/2       Actor    No    No   Yes  Yes  Yes   Yes     Slow   Passive
      ge-2/0/2     Partner    No    No   Yes  Yes  Yes   Yes     Slow    Active
      ge-2/0/6       Actor    No    No   Yes  Yes  Yes   Yes     Slow   Passive
      ge-2/0/6     Partner    No    No   Yes  Yes  Yes   Yes     Slow    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      ge-11/0/2                 Current   Slow periodic Collecting distributing
      ge-11/0/6                 Current   Slow periodic Collecting distributing
      ge-2/0/2                  Current   Slow periodic Collecting distributing
      ge-2/0/6                  Current   Slow periodic Collecting distributing

Unfortunately I'm still not able to ping ex host 10.32.43.132 (v43) with source 10.32.222.254 (reth2.222)

@srx> ping 10.32.43.123

PING 10.32.43.123 (10.32.43.123): 56 data bytes
64 bytes from 10.32.43.123: icmp_seq=0 ttl=128 time=16.685 ms

@srx> ping 10.32.43.123 source 10.32.43.254
PING 10.32.43.123 (10.32.43.123): 56 data bytes
64 bytes from 10.32.43.123: icmp_seq=0 ttl=128 time=19.411 ms

@srx> ping 10.32.43.123 source 10.32.222.254
PING 10.32.43.123 (10.32.43.123): 56 data bytes
^C
--- 10.32.43.123 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

@srx> show interfaces terse | match 10.32.222.
reth2.222                up    up   inet     10.32.222.254/24

@srx> show configuration security policies | match v43 | display set
set security policies from-zone management-v43 to-zone admin-v222 policy 4 match source-address any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 match destination-address any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 match application any
set security policies from-zone management-v43 to-zone admin-v222 policy 4 then permit
set security policies from-zone management-v43 to-zone admin-v222 policy 4 then log session-init
set security policies from-zone management-v43 to-zone admin-v222 policy 4 then log session-close
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match source-address any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match destination-address any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 match application any
set security policies from-zone admin-v222 to-zone management-v43 policy 5 then permit
set security policies from-zone admin-v222 to-zone management-v43 policy 5 then log session-init
set security policies from-zone admin-v222 to-zone management-v43 policy 5 then log session-close

Any idea what else might be causing this issue?

Many thanks,

Patryk

Hi Patryk,

Can you please share a flow trace for the traffic thats not working from the SRX side.

configure the following for capturing the flow.

set security flow traceoptions file flowtrace files 5 size 5m

set security flow traceoptions flag basic-datapath

set security flow traceoptions packet-filter pf1 source-prefix 10.32.222.254/32 destination-prefix 10.32.43.123/32 protocol icmp

set security flow traceoptions packet-filter pf2 source-prefix 10.32.43.123/32 destination-prefix 10.32.222.254/32 protocol icmp

initiate ping and then look for the flow trace.

Look for the flow and see if there is any drop/deny in the flow trace.

show log flowtrace | find deny

regards,

Guru Prasad

HI Guru,

I've configured the flow trace as you mentioned.

@srx> show configuration | display set | match traceoptions
set security flow traceoptions file flowtrace
set security flow traceoptions file size 5m
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter pf1 protocol icmp
set security flow traceoptions packet-filter pf1 source-prefix 10.32.222.254/32
set security flow traceoptions packet-filter pf1 destination-prefix 10.32.43.123/32
set security flow traceoptions packet-filter pf2 protocol icmp
set security flow traceoptions packet-filter pf2 source-prefix 10.32.43.123/32
set security flow traceoptions packet-filter pf2 destination-prefix 10.32.222.254/32

@srx> show log flowtrace | find deny

Pattern not found
{primary:node0}
@srx0>

@srx> show log flowtrace | match 10.32.43.123

Jul  5 14:52:57 14:53:36.842432:CID-2:RT:  route to 10.32.43.123
Jul  5 14:52:57 14:53:36.839123:CID-2:RT:<10.32.222.254/101->10.32.43.123/20374;1> matched filter pf1:
Jul  5 14:52:57 14:53:36.839191:CID-2:RT:  .local..0:10.32.222.254->10.32.43.123, icmp, (8/0)
Jul  5 14:52:57 14:53:36.839191:CID-2:RT: find flow: table 0x51c672c0, hash 13383(0xffff), sa 10.32.222.254, da 10.32.43.123, sp 101, dp 20374, proto 1, tok 2
Jul  5 14:52:57 14:53:36.839191:CID-2:RT:  flow_first_in_dst_nat: in <.local..0>, out <N/A> dst_adr 10.32.43.123, sp 101, dp 20374
Jul  5 14:52:57 14:53:36.839191:CID-2:RT:flow_first_rule_dst_xlate: packet 10.32.222.254->10.32.43.123 nsp2 0.0.0.0->10.32.43.123.
Jul  5 14:52:57 14:53:36.839191:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.32.222.254, x_dst_ip 10.32.43.123, in ifp .local..0, out ifp N/A sp 101, dp 20374, ip_proto 1, tos 0
Jul  5 14:52:57 14:53:36.839422:CID-2:RT:  routed (x_dst_ip 10.32.43.123) from junos-host (.local..0 in 0) to reth2.43, Next-hop: 10.32.43.123
Jul  5 14:52:57 14:53:36.839422:CID-2:RT:             10.32.222.254/2048 -> 10.32.43.123/2424 proto 1
Jul  5 14:52:57 14:53:36.839422:CID-2:RT:is_loop_pak: No loop: on ifp: reth2.43, addr: 10.32.43.123, rtt_idx:0
Jul  5 14:52:58 14:53:37.845441:CID-2:RT:<10.32.222.254/102->10.32.43.123/20374;1> matched filter pf1:
Jul  5 14:52:58 14:53:37.845560:CID-2:RT:  .local..0:10.32.222.254->10.32.43.123, icmp, (8/0)
Jul  5 14:52:58 14:53:37.845575:CID-2:RT: find flow: table 0x51c672c0, hash 5431(0xffff), sa 10.32.222.254, da 10.32.43.123, sp 102, dp 20374, proto 1, tok 2
Jul  5 14:52:58 14:53:37.845638:CID-2:RT:  flow_first_in_dst_nat: in <.local..0>, out <N/A> dst_adr 10.32.43.123, sp 102, dp 20374
Jul  5 14:52:58 14:53:37.845638:CID-2:RT:flow_first_rule_dst_xlate: packet 10.32.222.254->10.32.43.123 nsp2 0.0.0.0->10.32.43.123.
Jul  5 14:52:58 14:53:37.845638:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.32.222.254, x_dst_ip 10.32.43.123, in ifp .local..0, out ifp N/A sp 102, dp 20374, ip_proto 1, tos 0
Jul  5 14:52:58 14:53:37.845735:CID-2:RT:  routed (x_dst_ip 10.32.43.123) from junos-host (.local..0 in 0) to reth2.43, Next-hop: 10.32.43.123
Jul  5 14:52:58 14:53:37.845735:CID-2:RT:             10.32.222.254/2048 -> 10.32.43.123/60406 proto 1
Jul  5 14:52:58 14:53:37.845735:CID-2:RT:is_loop_pak: No loop: on ifp: reth2.43, addr: 10.32.43.123, rtt_idx:0
Jul  5 14:52:58 14:53:37.847777:CID-2:RT:<10.32.43.123/20374->10.32.222.254/102;1> matched filter pf2:
Jul  5 14:52:58 14:53:37.847777:CID-2:RT:  reth2.222:10.32.43.123->10.32.222.254, icmp, (0/0)
Jul  5 14:52:58 14:53:37.847777:CID-2:RT: find flow: table 0x51c672c0, hash 30521(0xffff), sa 10.32.43.123, da 10.32.222.254, sp 20374, dp 102, proto 1, tok 19
Jul  5 14:52:58 14:53:37.848279:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.32.43.123, x_dst_ip 10.32.222.254, in ifp reth2.222, out ifp N/A sp 20374, dp 102, ip_proto 1, tos 0
Jul  5 14:52:58 14:53:37.848279:CID-2:RT:             10.32.43.123/0 -> 10.32.222.254/62454 proto 1
Jul  5 14:52:58 14:53:37.848279:CID-2:RT:  dip id = 0/0, 10.32.43.123/20374->10.32.43.123/20374 protocol 0
Jul  5 14:52:58 14:53:37.848780:CID-2:RT:  route lookup: dest-ip 10.32.43.123 orig ifp reth2.222 output_ifp reth2.43 orig-zone 19 out-zone 13 vsd 1
Jul  5 14:52:58 14:53:37.848780:CID-2:RT:  route to 10.32.43.123
Jul  5 14:53:01 14:53:41.299517:CID-2:RT:<10.32.43.123/20388->10.32.222.254/0;1> matched filter pf2:
Jul  5 14:53:01 14:53:41.299517:CID-2:RT:  reth2.222:10.32.43.123->10.32.222.254, icmp, (0/0)
Jul  5 14:53:01 14:53:41.299517:CID-2:RT: find flow: table 0x51c672c0, hash 34467(0xffff), sa 10.32.43.123, da 10.32.222.254, sp 20388, dp 0, proto 1, tok 19
Jul  5 14:53:01 14:53:41.300018:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.32.43.123, x_dst_ip 10.32.222.254, in ifp reth2.222, out ifp N/A sp 20388, dp 0, ip_proto 1, tos 0
Jul  5 14:53:01 14:53:41.300018:CID-2:RT:             10.32.43.123/0 -> 10.32.222.254/18710 proto 1
Jul  5 14:53:01 14:53:41.300018:CID-2:RT:  dip id = 0/0, 10.32.43.123/20388->10.32.43.123/20388 protocol 0
Jul  5 14:53:01 14:53:41.300608:CID-2:RT:  route lookup: dest-ip 10.32.43.123 orig ifp reth2.222 output_ifp reth2.43 orig-zone 19 out-zone 13 vsd 1
Jul  5 14:53:01 14:53:41.300671:CID-2:RT:  route to 10.32.43.123
Jul  5 14:53:01 14:53:41.297230:CID-2:RT:<10.32.222.254/0->10.32.43.123/20388;1> matched filter pf1:
Jul  5 14:53:01 14:53:41.297288:CID-2:RT:  .local..0:10.32.222.254->10.32.43.123, icmp, (8/0)
Jul  5 14:53:01 14:53:41.297288:CID-2:RT: find flow: table 0x51c672c0, hash 61697(0xffff), sa 10.32.222.254, da 10.32.43.123, sp 0, dp 20388, proto 1, tok 2
Jul  5 14:53:01 14:53:41.297288:CID-2:RT:  flow_first_in_dst_nat: in <.local..0>, out <N/A> dst_adr 10.32.43.123, sp 0, dp 20388
Jul  5 14:53:01 14:53:41.297288:CID-2:RT:flow_first_rule_dst_xlate: packet 10.32.222.254->10.32.43.123 nsp2 0.0.0.0->10.32.43.123.
Jul  5 14:53:01 14:53:41.297288:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.32.222.254, x_dst_ip 10.32.43.123, in ifp .local..0, out ifp N/A sp 0, dp 20388, ip_proto 1, tos 0
Jul  5 14:53:01 14:53:41.297511:CID-2:RT:  routed (x_dst_ip 10.32.43.123) from junos-host (.local..0 in 0) to reth2.43, Next-hop: 10.32.43.123
Jul  5 14:53:01 14:53:41.297511:CID-2:RT:             10.32.222.254/2048 -> 10.32.43.123/16662 proto 1
Jul  5 14:53:01 14:53:41.297511:CID-2:RT:is_loop_pak: No loop: on ifp: reth2.43, addr: 10.32.43.123, rtt_idx:0

I think I should mention about one important thing.

In our environment we have a cluster of two SRX 650's. Each cluster resides in different location.

Between these two locations we have a L2 connection established.

The host with IP address 10.32.43.123 has a DG set to 10.32.43.1.

The DG 10.32.43.1 (reth1.43) is configured on SRX_A in 1st location.

The test above has been initiated from SRX_B in 2nd location.

That means that icmp request was sent as follows

SRX_B (in 2nd location) reth 2.222 (10.32.222.254) -> reth2.43 (10.32.43.254) -> host 10.32.43.123

It seems there is no return path.

In my understanding if client want's to reply for an ICMP request from 10.32.222.254 he will send reply to his DG which is 10.32.43.1 (SRX in location A)

SRX in location A will notice that destination IP is 10.32.222.254.

From the routing table there is a directly connected int in network 10.32.222.0/24

@srxA> show route 10.32.222.254

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

10.32.222.0/24     *[Direct/0] 13w2d 12:26:12
                    > via reth1.222

Hope that make sense.

Thx

Hi,

I did a flowtrace on SRX_A

If I understand correctly the SRX_A is trying to send reply from int reth1.43 to reth1.222

@srx_A> show log flowtrace | find 10.32.222.254
Jul  5 12:02:29 12:02:29.312058:CID-1:RT:<10.32.43.123/20609->10.32.222.254/196;1> matched filter pf2:

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:packet [84] ipid = 17765, @437d3e24

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:---- flow_process_pkt: (thd 5): flow_ctxt type 13, common flag 0x0, mbuf 0x437d3c00, rtbl_idx = 0

Jul  5 12:02:29 12:02:29.312058:CID-1:RT: flow process pak fast ifl 79 in_ifp reth1.43

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:  reth1.43:10.32.43.123->10.32.222.254, icmp, (0/0)

Jul  5 12:02:29 12:02:29.312058:CID-1:RT: find flow: table 0x54c382f0, hash 62614(0xffff), sa 10.32.43.123, da 10.32.222.254, sp 20609, dp 196, proto 1, tok 14

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:self ip check: not for self (address=0a20defe)

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:  flow_first_create_session

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:  flow_first_in_dst_nat: in <reth1.43>, out <N/A> dst_adr 10.32.222.254, sp 20609, dp 196

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:  chose interface reth1.43 as incoming nat if.

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.32.222.254(196)

Jul  5 12:02:29 12:02:29.312058:CID-1:RT:flow_first_routing: call flow_route_lookup(): src_ip 10.32.43.123, x_dst_ip 10.32.222.254, in ifp reth1.43, out ifp N/A sp 20609, dp 196, ip_proto 1, tos 0

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:Doing DESTINATION addr route-lookup

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  routed (x_dst_ip 10.32.222.254) from management-v43 (reth1.43 in 1) to reth1.222, Next-hop: 10.32.222.254

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  policy search from zone management-v43-> zone admin-v222 (0x0,0x508100c4,0xc4)

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  app 0, timeout 60s, curr ageout 60s

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  dip id = 0/0, 10.32.43.123/20609->10.32.43.123/20609

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  choose interface reth1.222 as outgoing phy if

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:is_loop_pak: No loop: on ifp: reth1.222, addr: 10.32.222.254, rtt_idx:0

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  check nsrp pak fwd: in_tun=0x0, VSD 1 for out ifp reth1.222

Jul  5 12:02:29 12:02:29.312561:CID-1:RT:  vsd 1 is active

Your help is greatly appreciated

Thx

Patryk

Hi,

FYI I did a simle packet capture from host 10.32.43.123.

I do see it replying to 10.32.222.254.

However I'm not able to ping 10.32.222.254 (reth2.222 srx_b) from host 10.32.43.123.

I can ping 10.32.222.1 (reth1.222 srx_a)

I aslo noticed that I can't ping 10.32.222.254 (reth2.222 srx_b) with source 10.32.43.1 (reth1.43 srx_a)

Hi Patryk,

You have configured two interfaces reth1.222 and reth2.222 with IP addresses from the same subnet. This is incorrect.

Please take a look at https://kb.juniper.net/InfoCenter/index?page=content&id=TN260

It should help you to understand how reth interfaces work.

Regards, Wojtek

Hi Wojtek
Unfortunately that's not true.
Sorry for the confusion.

Reth1 interface is configured on SRX in location A
Reth2 interface is configured on SRX in location B

in each location there is a cluster of SRX firewalls

The ping doesn't work from SRX in location B {Reth2. 43}
Below I've attached a simple drawing which shows a part of network infrastructure

Hope this clears up a lot of confusion

Thx

Hi Patryk, sorry for the last message. I though you have single chassis cluster with both nodes in seperate sites.

Now it makes much more sense.

In this scenario you have an asymmetric traffic. When you initiate ping from host 10.32.43.123 to 10.32.222.254 the packet on srx in location B is received on reth2.222 but response is leaving through reth2.43.

Do you maybe have an ip spoofing screen configured? That would explain why the traffic is dropped.

Regards, Wojtek