SRX

Hello.

I am unable to ping my loopback address from a connected host in the same zone. I have intra zone traffic in the zone enabled and can confirm that I can reach the loopback address from a layer 3 hop, but it's not working over a layer 2.

So if I have a host at 10.10.20.150 pinging 10.10.10.1 it works (both 10.10.10.0/24 and 10.10.20.0/24 can reach other via ospf). However, if I plug a host into fe-0/0/2 and it gets an IP of 10.10.10.150, that host cannot ping 10.10.10.1, but it can ping 10.10.10.2.

config:

set system services dhcp pool 10.10.10.0/24 address-range low 10.10.10.100
set system services dhcp pool 10.10.10.0/24 address-range high 10.10.10.200
set system services dhcp pool 10.10.10.0/24 router 10.10.10.2
set system services dhcp propagate-settings vlan.1

set interfaces fe-0/0/2 unit 0 description trust
set interfaces fe-0/0/2 unit 0 family ethernet-switching vlan members vlan1

set interfaces lo0 unit 0 description loopback
set interfaces lo0 unit 0 family inet address 10.10.10.1/32
set interfaces vlan unit 1 description trust
set interfaces vlan unit 1 family inet address 10.10.10.2/24

set protocols ospf area 0.0.0.0 interface vlan.1 priority 1
set protocols ospf area 0.0.0.0 interface lo0.0 passive

set security policies from-zone trust to-zone trust policy trust-to-trust match source-address any
set security policies from-zone trust to-zone trust policy trust-to-trust match destination-address any
set security policies from-zone trust to-zone trust policy trust-to-trust match application any
set security policies from-zone trust to-zone trust policy trust-to-trust then permit

set security zones security-zone trust interfaces vlan.1 host-inbound-traffic system-services all
set security zones security-zone trust interfaces vlan.1 host-inbound-traffic protocols ospf
set security zones security-zone trust interfaces lo0.0 host-inbound-traffic system-services all

set vlans vlan1 vlan-id 3
set vlans vlan1 l3-interface vlan.1

What am I missing, or is this just not possible on the SRX?

Hi,

The SRX doesn't by default proxy arps it loopback addresses.

When trying to ping the lo0.0 from the 10.10.10.0/24 subnet, the host ARPs for 10.10.10.1, since it should be in its Layer 2 network, but the SRX doesn't respond to this arp request (this is by design, AFAIK only Linux boxes proxy-arp to theirs device addressess anyway).

The simplest workaround is to add the following config:

 set security nat proxy-arp interface vlan.1 address 10.10.10.1

Regards,

Mircho

Thanks, I had already tried that, I just set it again and it still isn't working.

Could there be some other config missing to make the proxy-arp work on the vlan interface? I am allowing host-inbound-traffic system-services all on lo0.0 already.

Your configuration looks fine, what I feel is the Proxy-ARP may not be working as expected. Can you check the ARP table on 10.10.10.150 and see if it has a valid entry for '10.10.10.1".

If you dont see an ARP entry, try adding statically and see if its working.

If you see the ARP entry, then add flow traceoptions on SRX and check the logs. Following URL explains flow traceoptions on SRX http://kb.juniper.net/InfoCenter/index?page=content&id=KB16110

Thanks,

Suraj

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too

If I add the ARP entry statically it works as expected, so it looks like proxy-arp isn't working as expected.

Should this be logged with Juniper as an issue or is there anything else we can try? This is the line in my config by the way 

set security nat proxy-arp interface vlan.1 address 10.10.10.1/32

Hi mans, can you help me with similar problem.
I have two Firefly 12.1x47-D15.4 virtual machines with this configuration:

R1:

set version 12.1X47-D15.4
set system host-name R1
set system root-authentication encrypted-password "$1$MZSDeWoR$.e1KicC9QzerG.7NWwg8w/"
set system services ssh
set system services web-management http interface ge-0/0/0.0
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set interfaces ge-0/0/0 unit 0 family inet address 192.180.10.1/24
set interfaces ge-0/0/1 unit 0 family inet address 200.172.50.1/24
set interfaces ge-0/0/2 unit 0 family inet address 192.168.200.1/24
set routing-options static route 2.2.2.2/32 next-hop 192.180.10.2
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set security zones security-zone untrust host-inbound-traffic system-services all
set security zones security-zone untrust host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/2.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/2.0 host-inbound-traffic protocols all

R2:


set version 12.1X47-D15.4
set system host-name R2
set system root-authentication encrypted-password "$1$MZSDeWoR$.e1KicC9QzerG.7NWwg8w/"
set system services ssh
set system services web-management http interface ge-0/0/0.0
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set interfaces ge-0/0/0 unit 0 family inet address 192.180.10.2/24
set interfaces ge-0/0/1 unit 0 family inet address 35.48.27.2/24
set interfaces ge-0/0/2 unit 0 family inet address 192.168.200.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set security zones security-zone untrust host-inbound-traffic system-services all
set security zones security-zone untrust host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic protocols all
set security zones security-zone untrust interfaces ge-0/0/2.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces ge-0/0/2.0 host-inbound-traffic protocols all
set security zones security-zone untrust interfaces lo0.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces lo0.0 host-inbound-traffic protocols all

Firstly add static route on R1:
set routing-options static route 2.2.2.2/32 next-hop 192.180.10.2
and cannot ping 2.2.2.2 ip address 😞

Secondly add ospf protocol and have next:

root@R1# run show route

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

2.2.2.2/32         *[Static/5] 01:14:44
                    > to 192.180.10.2 via ge-0/0/0.0
                    [OSPF/10] 01:13:55, metric 1
                    > to 192.180.10.2 via ge-0/0/0.0
35.48.27.0/24      *[OSPF/10] 01:13:55, metric 2
                    > to 192.180.10.2 via ge-0/0/0.0
192.168.200.0/24   *[Direct/0] 01:14:44
                    > via ge-0/0/2.0
192.168.200.1/32   *[Local/0] 01:14:49
                      Local via ge-0/0/2.0
192.180.10.0/24    *[Direct/0] 01:14:44
                    > via ge-0/0/0.0
192.180.10.1/32    *[Local/0] 01:14:49
                      Local via ge-0/0/0.0
200.172.50.0/24    *[Direct/0] 01:14:44
                    > via ge-0/0/1.0
200.172.50.1/32    *[Local/0] 01:14:49
                      Local via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 01:16:07, metric 1
                      MultiRecv

I have routes to 2.2.2.2/32 and 35.48.27.0/24 networks, but:

From R1:

root@R1# run ping 192.180.10.2
PING 192.180.10.2 (192.180.10.2): 56 data bytes
64 bytes from 192.180.10.2: icmp_seq=0 ttl=64 time=30.653 ms
64 bytes from 192.180.10.2: icmp_seq=1 ttl=64 time=24.534 ms
64 bytes from 192.180.10.2: icmp_seq=2 ttl=64 time=13.857 ms
64 bytes from 192.180.10.2: icmp_seq=3 ttl=64 time=16.957 ms
64 bytes from 192.180.10.2: icmp_seq=4 ttl=64 time=22.879 ms
^C
--- 192.180.10.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 13.857/21.776/30.653/5.892 ms


root@R1# run ping 2.2.2.2         
PING 2.2.2.2 (2.2.2.2): 56 data bytes
^C
--- 2.2.2.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss


root@R1# run ping 35.48.27.2 source 192.180.10.1    
PING 35.48.27.2 (35.48.27.2): 56 data bytes
^C
--- 35.48.27.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss



root@R1# run ping 35.48.27.2 source 192.168.200.1   
PING 35.48.27.2 (35.48.27.2): 56 data bytes
^C
--- 35.48.27.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

From R2:

root@R2# run ping 192.180.10.1        
PING 192.180.10.1 (192.180.10.1): 56 data bytes
64 bytes from 192.180.10.1: icmp_seq=0 ttl=64 time=34.908 ms
64 bytes from 192.180.10.1: icmp_seq=1 ttl=64 time=15.506 ms
64 bytes from 192.180.10.1: icmp_seq=2 ttl=64 time=16.031 ms
^C
--- 192.180.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.506/22.148/34.908/9.025 ms


root@R2# run ping 192.168.200.1   
.PING 192.168.200.1 (192.168.200.1): 56 data bytes
64 bytes from 192.168.200.1: icmp_seq=0 ttl=64 time=187.157 ms
64 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=15.319 ms
64 bytes from 192.168.200.1: icmp_seq=2 ttl=64 time=15.164 ms
^C
--- 192.168.200.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.164/72.547/187.157/81.042 ms


root@R2# run ping 192.180.10.1 source 2.2.2.2
PING 192.180.10.1 (192.180.10.1): 56 data bytes
64 bytes from 192.180.10.1: icmp_seq=0 ttl=64 time=37.191 ms
64 bytes from 192.180.10.1: icmp_seq=1 ttl=64 time=19.352 ms
64 bytes from 192.180.10.1: icmp_seq=2 ttl=64 time=15.870 ms
^C
--- 192.180.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.870/24.138/37.191/9.339 ms


root@R2# run ping 192.180.10.1 source 35.48.27.2    
PING 192.180.10.1 (192.180.10.1): 56 data bytes
64 bytes from 192.180.10.1: icmp_seq=0 ttl=64 time=27.837 ms
64 bytes from 192.180.10.1: icmp_seq=1 ttl=64 time=15.307 ms
64 bytes from 192.180.10.1: icmp_seq=2 ttl=64 time=17.866 ms
^C
--- 192.180.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.307/20.337/27.837/5.405 ms

Can you help me, what wrong ?

have you added lo0.0 into the right securtiy zone ?

set security zones security-zone untrust interfaces lo0.0  host-inbound-traffic system-services ping

I used untrust but i also can be an other zone on your SRX that lo0 shout be in.

Hi MarcTB. I provided all my configuration. And i have this:

set security zones security-zone untrust interfaces lo0.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces lo0.0 host-inbound-traffic protocols all

This is enough ?

nevermind I have not seen that in you config! I checked again and saw it! My bad!

Yes that should be enough. You also have a policy that allows traffic comming in on the untrust zone ?

Marc, i presented all my configuration and im not strong in security. I need use this vsrx machines as a routers. Can you help me, which right policy i need ?

Hi mgarrido,

Please open a case with Juniper TAC.

Thanks,

Suraj

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too

Why do you have your lo0.0 and your vlan.1 interfaces in the same subnet?  This is the reason why it is not working.  You can't have your vlan.1 interface be the 10.10.10.0/24 subnet, but then break a single IP address out onto another interface like lo0.0 and expect it to work.  Change your loopback IP to something else, make vlan.1 10.10.10.1 and use that as your default gateway.

@evt: Where is it documented that I can't do this? This works in every other device I've configured, ScreenOS included. I can ping it just fine over layer 3, why doesn't the appliance properly proxy arp the address?

I'll open a J-Tac support case since it seems the SRX is not doing what it is supposed to be doing, my configs are all correct and there's no reason why it shouldn't do this.

My mistake, then.  I've never seen or worked with a configuration before that uses a loopback in the same subnet as another interface on the device.  If it's supposed to work and there's a need for it, then you're right - opening a case is the best course of action.

Can you configure this?

set interfaces vlan.1 proxy-arp 

 I tested this out in my lab with your configurtion and it seems to work.  I got this information from here:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB20789

EDIT:  This was in a lab environment, so the ramifications for enabling proxy-arp on the vlan.1 interface may not be what you want in the end.

Thanks, that worked, and yes, it's what I want to do.

Do you have examples of any negative ramifications of enabling proxy arp on the vlan interface? I can't think of any to be honest.

Specific examples, no.  Past experience where customers had proxy-arp enabled on their Cisco router LAN interfaces, yes.  What I've seen happen is that all destinations that LAN users go to - and I mean ALL destinations - suddenly would have an ARP entry in the router's ARP table.  I can honestly say that I haven't worked with proxy-arp in years, so things may have changed in newer IOS.  That said, the fact that Juniper defaults to 'restricted' mode, I believe mitigates this behavior.  Others more knowledgeable with proxy-arp behavior can feel free to chime in.

Ok, I think in my particular scenario it will also be mitigated since vlan.1 is for management traffic only, all my users will actually be using a switch as the default gateway. The loopback address will only be reached via ARP when there's a directly connected host that needs to talk to the SRX.

I'll keep an eye on the ARP table of the SRX just in case, thanks for bringing it up.