SRX

I've found all of the docs and troubleshooting guides and think everything is configured properly. I've gone through the guide (https://kb.juniper.net/InfoCenter/index?page=content&id=KB21922&actp=METADATA) and double checked. I'm currently testing with just one internal IP/machine.

 

Here's the short version:

Internal machine 10.20.15.172 connected to ge-0/0/1.0 (10.20.15.254).

Outside (cable modem) 172.20.15.1 connected to ge-0/0/0.0 (172.20.15.254).

 

If I setup the source nat rule to use the interface (10.20.15.254), everything works just fine.

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match source-address 10.20.15.128/26

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match source-address 10.20.15.100/32

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match source-address 10.20.15.101/32

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match source-address 10.20.15.250/32

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match source-address 10.20.15.210/32

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet match destination-address-name ADDR_ANY_IPV4

set security nat source rule-set NAT_SRCE_HOME_LAN rule HOME-LAN_to_Internet then source-nat interface

When I set it up to use the source pool

set security nat source pool NAT_SRCE_POOL_HOME_LAN description "NAT SOURCE POOL FOR HOME-LAN to INTERNET CONNECTIONS"

set security nat source pool NAT_SRCE_POOL_HOME_LAN address 172.20.15.172/32

set security nat source pool NAT_SRCE_POOL_HOME_LAN port no-translation

set security nat source pool NAT_SRCE_POOL_HOME_LAN address-pooling paired

 

If I get onto .172 and try to ping out, it fails:

user@barney:~$ ping -c1 23.216.159.40

PING 23.216.159.40 (23.216.159.40) 56(84) bytes of data.

--- 23.216.159.40 ping statistics ---

1 packets transmitted, 0 received, 100% packet loss, time 0ms

 

At the same time, I see the flow session on the SRX:

root@GreatGazoo> show security flow session source-prefix 10.20.15.172 destination-prefix 23.216.159.40 protocol icmp

cSession ID: 7818, Policy name: HOME_LAN_Internet/9, Timeout: 48, Valid

In: 10.20.15.172/1 --> 23.216.159.40/7051;icmp, If: ge-0/0/1.0, Pkts: 1, Bytes: 84

Out: 23.216.159.40/7051 --> 172.20.15.172/1;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Total sessions: 1

 

I also did setup traceoptions and verified that the session was created there but don't want to waste space pasting that in.

 

Finally, when I monitor the interface (the one connected from the SRX to the cable modem), I see the arp requests:

root@GreatGazoo> monitor traffic interface ge-0/0/0 no-resolve no-domain-names

verbose output suppressed, use or for full protocol decode

Address resolution is OFF.

Listening on ge-0/0/0, capture size 96 bytes

18:08:59.573682 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

18:09:18.483741 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

18:09:39.737295 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

 

But as you can see, the SRX is not replying 😞 😞 even though the proxy-arp is setup:

 

root@GreatGazoo> show configuration security nat proxy-arp |display set

set security nat proxy-arp interface ge-0/0/0.0 address 172.20.15.172/32

 

I also did check the hit counts on the nat rule and pool after clearing them and they both showed 1 hit with the single ping.

 

So best I can tell, the ping is getting out of the machine to the ingress of the SRX (ge-0/0/1.0) as 10.20.15.172 destined for 23.216.159.40. It is then natted to 172.20.15.172 and destined to leave the SRX out ge-0/0/0.0 which I can assume that it does since a moment later I see an arp request on ge-0/0/0.0 looking for 172.20.15.172. The request is coming from 73.xx.xx.x7 which is the WAN side interface of the cable modem - hence the assumption that the ping went out. So why does the SRX not answer the arp request for an IP that is in the range of what proxy-arp is set to - which in this case for testing is a single IP address, 172.20.15.172.

 

Appreciate any suggestions you may have and if you need additional information, I can provide it.

can you configure ip 172.20.15.172 on lo0.0 interface and check if you can ping any address on the wan with src 172.20.15.172 ? 

 

---

@akushner wrote:

can you configure ip 172.20.15.172 on lo0.0 interface and check if you can ping any address on the wan with src 172.20.15.172 ? 

---

I tried to configure a loopback interface as suggested:

set interfaces lo0 unit 0 description "Loopback for testing NAT issue using 172.20.15.x as NAT pool"

set interfaces lo0 unit 0 family inet address 172.20.15.172/24

 

I then initiated a ping to the outside:

root@GreatGazoo> ping verbose inet 23.216.159.40 source 172.20.15.172 record-route no-resolve

PING 23.216.159.40 (23.216.159.40): 56 data bytes

 

While monitoring the WAN facing interface (ge-0/0/0):

root@GreatGazoo> monitor traffic interface ge-0/0/0 no-resolve matching "src 172.20.15.172"     

verbose output suppressed, use <detail> or <extensive> for full protocol decode

Address resolution is OFF.

Listening on ge-0/0/0, capture size 96 bytes

 

19:56:55.594415 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:56:56.597524 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:56:57.599450 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:56:58.603074 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:56:59.604790 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:57:00.606073 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:57:01.607512 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:57:02.609225 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:57:03.610746 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

19:57:04.616081 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]

 

Clearly the echo request was getting out of the interface (or at least to the point where monitor traffic saw it) but there appears to be not attempt at reply. I'm guessing I may have something else that isn't setup properly? There should not be any firewall filters in between as there are only input filters on ge-0/0/0 and did not see any deny messages.

 

I don't have any routing instances set up but maybe I need to add a security policy to allow the 172.20.15.x out? Since I'm pinging from an inside interface (lo0) that isn't included in any zone, could that be why it's appearing to not leave?

Hi,

Your configuration is correct. But you are getting the arp request from the modem's WAN ip address. It should be from the LAN address of the modem, like below:

18:08:59.573682 In arp who-has 172.20.15.172 tell 172.20.15.254

 

Hi,

SRX will not reply to the arp requests if the request is not in the same subnet range. In this case, srx subnet is 172.20.15.0/24 and the arp request is coming from different subnet 73.x.x.x. Try to add static arp entry for 172.20.15.172  in DSL modem, if possible.

 

---

@Nellikka wrote:

Hi,

SRX will not reply to the arp requests if the request is not in the same subnet range. In this case, srx subnet is 172.20.15.0/24 and the arp request is coming from different subnet 73.x.x.x. Try to add static arp entry for 172.20.15.172  in DSL modem, if possible.

 

---

If you are correct, then maybe I'm reading the instructions wrong? Following this (https://kb.juniper.net/InfoCenter/index?page=content&id=KB21611&actp=METADATA) troubleshooting guide, it clearly shows that the nat pool needs to be in the same subnet as the external SRX interface.

 

3. Is the NAT pool from the same subnet as the SRX external interface?  (For example, if the NAT pool is 1.1.1.2 thru 1.1.1.4, and the SRX external IP address is 1.1.1.1/24, then the NAT pool is on the same subnet as the SRX external IP address.) 

• Yes - Continue with Step 4
• No - Continue with Step 5

4. Run the configuration command:  show security nat proxy-arp

Is Proxy ARP configured for the NAT pool IP addresses?  For more information on Proxy ARP and how to configure it; go to KB21785 - [SRX] When and how to configure Proxy ARP.

• Yes - Continue with Step 5
• No - Configure Proxy ARP, and run the traffic to retest. If it still fails, continue to Step 5.

Follwing the link for how to configure Proxy ARP it states:

When to configure Proxy ARP

As specified in Configuring Proxy ARP (CLI Procedure), Proxy ARP should be configured for the following scenarios:

• When addresses defined in the static NAT and source NAT pool are in the same subnet as that of the ingress interface   (Source NAT and Static NAT scenario)

 What you seem to be saying is that I need to configure this for the outside, public, IP space not the subnet that the ingress (for return packets) interface's subnet.

 

Also, in the original post, the arp requests were hitting the ingress interface saying where is the 172.20.15.172/32. Since the interface is in the 172.20.15.0/24 subnet, shouldn't it answer?

 

I must be reading something wrong so I appreciate if you could point it out.

 

Hi Alfonso,

 

ARP is intended for resolving the MAC addresses of devices within the same L2 domain (same subnet). In this case the modem should only send an ARP request towards the SRX if the destination address of the reply packet (172.20.15.172) is within the same subnet of one of its local interfaces (172.20.15.1). In our case, this is true, however the ARP request sent to the SRX should be sourced from an IP address on that subnet (172.20.15.0/24) and as you can see the arp request is sourced from an address of a different subnet:

 

root@GreatGazoo> monitor traffic interface ge-0/0/0 no-resolve no-domain-names

verbose output suppressed, use or for full protocol decode

Address resolution is OFF.

Listening on ge-0/0/0, capture size 96 bytes

18:08:59.573682 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

18:09:18.483741 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

18:09:39.737295 In arp who-has 172.20.15.172 tell 73.xx.xx.x7

 

I will engage the modem provider to verify this odd behavior. Also go ahead and disconnect/connect this connection and see if the ARP works fine after that. Also you can reboot the modem, this often resolves this weird behaviors.

 

If the problem remains, you will have to insert a static route in the modem to point to 172.20.15.254 whenever the modem wants to send packets to 172.20.15.172.

 

I hope this info helps.

 

I'm not sure if I can setup a static route on the modem that points back in but I'll check. I'm actually replacing the modem as it's probaby over 5 years old - which isn't old but ... - and it's been displaying other wierd behavior that indicates a hardware type of issue so for > $200 I can get a new one and get a good 5-7 years out of it and be good.

 

I also did some more reading and found this:

Restricted Proxy ARP

Restricted proxy ARP enables the router or switch to respond to the ARP requests in which the physical networks of the source and target are not the same and the router or switch has an active route to the target address in the ARP request. The router does not reply if the target address is on the same subnet and the same interface as the ARP requestor.

Unrestricted Proxy ARP

Unrestricted proxy ARP enables the router or switch to respond to any ARP request, on condition that the router has an active route to the destination address of the ARP request. The route is not limited to the incoming interface of the request, nor is it required to be a direct route.

When an IP client broadcasts the ARP request across the Ethernet wire, the end node with the correct IP address responds to the ARP request and provides the correct MAC address. If the unrestricted proxy ARP feature is enabled, the router response is redundant and might fool the IP client into determining that the destination MAC address within its own subnet is the same as the address of the router.

172 is likely old school in terms of design. When I think of 172 I remember my old HUB. They often had coaxial ports. I forget the name of the ports offhand. Coax is analog. Pass through is what I keep thinking. Good for an intranet. Windows Enterprise intranet at best(scarcely). Good for RPC. Good for the routing and remote modules. For that it should be all digital or better(I.C.). Take a mac with many letters. Not good. Mac with numbers is better. Find that same modem with a Mac that starts with numbers and only has two to three letters in it. Avoid C-E . Since it is I.C. most likely, you'll want to find that special Mac. Remember with analog in mind the trick back then was to jump gaps. Good luck. Windows will still do it. Others may not. Try using Windows server DHCP and the full routing and remote access on a network with 172 . You'll get the hint.

https://en.m.wikipedia.org/wiki/10BASE2

Wanted to update in case anyone searches and finds this for a possible solution.

 

The previous note about restricted and unrestricted seemed to do the trick. As noted in the article "Restricted proxy ARP enables the router or switch to respond to the ARP requests in which the physical networks of the source and target are not the same and the router or switch has an active route to the target address in the ARP request."

 

That's exactly the situation and by simply adding proxy-arp restricted to the interface along with a static nat pointing the 172.20.15.x to the 10.20.15.x, all seems to be working. I can now see the arp request coming into the interface and the reply going out saying ge-0/0/0 knows where that IP is.

 

Now just need to finish getting the entire /26 subnet setup.

 

Thanks for the input!!

I always wondered why RPC was so slow on a subnet of 172. I learned not to question it because it never got better. I imagine flow is important because of the technology that used to be used on the 172. Maybe improvement there is necessary. ARP takes advantage of today's alorithms. SRX ARP seems a bit lax to me. 172 likes round robin. Maybe improvement there is good too. Straight communication is a negative(point to point) there. Remember cable coax has two leads. Restricted is fixing this. Unrestricted is colliding. 172 is the culprit.

https://en.m.wikipedia.org/wiki/10BASE2
Type of coax is a factor, as are twisted pair and sheilding.