SRX

Hello,

 

Context: I'd like to be able to reach a destination network (78.x.y.z/32) via a specific interface (reth 1.112 : 172.28.x.2/30) from my source network (172.20.x.y/24). (I change the network for confidentiality):

 

So I just created a static route to this destination via the specific interface.

Then I created policies when I allow the traffic from source zone to the destination zone.

 

Results : 

1) When I try to ping/traceroute from the juniper to this destination, the route is working.

I can see the "hops" on the specific interface that I specified in the route. 

2) When I try to ping/traceroute from my source to this destination, the route doesn't work.

No ping answers, no hops in the traceroute results.

 

If you have any idea to help me to solve this ? Any debug commands ? 

 

I'll give you the configuration that I setup.

 

Policies :

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

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

 

Route : 

set routing-options static route 78.x.y.z/32 next-hop 172.28.x.1

 

Results : 

Simple ping without specifying the source OK : 

> ping 78.x.y.z
PING 78.x.y.z (78.x.y.z): 56 data bytes
64 bytes from 78.x.y.z: icmp_seq=0 ttl=254 time=4.238 ms
64 bytes from 78.x.y.z: icmp_seq=1 ttl=254 time=5.294 ms
^C
--- 78.x.y.z ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.238/4.766/5.294/0.528 ms

 

Traceroute OK :

> traceroute 78.x.y.z
traceroute to 78.x.y.z (78.x.y.z), 30 hops max, 40 byte packets
1 hop1 (172.28.x.1) 3.435 ms 1.262 ms 1.394 ms
2 hop2 (1.2.3.4) 2.344 ms 2.311 ms 2.357 ms
3 hop3 (78.x.y.z) 6.184 ms 5.215 ms 4.856 ms

 

Simple ping with source KO :

> ping 78.x.y.z source 172.20.x.254
PING 78.x.y.z (78.x.y.z): 56 data bytes

^C
--- 78.x.y.z ping statistics ---
854 packets transmitted, 0 packets received, 100% packet loss

 

Traceroute with source :

> traceroute 78.x.y.z source 172.20.x.254
traceroute to 78.x.y.z (78.x.y.z) from 172.20.x.254, 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * *^C

 

Best Regards,

John

Hi John,

Mostly the destination don’t have route back to the source. Can you add the below source NAT rule and test the behavior?


set security nat source rule-set TEST-NAT from zone zone-source -> zone where your client is connected

set security nat source rule-set TEST-NAT to zone zone-destination -> zone where your server is connected

set security nat source rule-set TEST-NAT rule 1 match destination-address 0.0.0.0/0

set security nat source rule-set TEST-NAT rule 1 then source-nat interface
commit

Hi Rsuraj,

 

Yes that could be that.

I tried what you suggested but it doesn't work. Same result as the original post. I can see in CLI > show security nat source rule : 

 

source NAT rule: 1 Rule-set: TEST-NAT
Rule-Id : 3
Rule position : 3
From zone : zone-source
To zone : zone-destination
Match
Source addresses : 172.20.x.0 - 172.20.x.255
Destination addresses : 78.x.y.z - 78.x.y.z
Action : interface
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 0
Successful sessions : 0
Failed sessions : 0
Number of sessions : 0

 

Best Regards,

John

Re rsuraj,

 

Something I noticed is that the new rule-set that's been created doesn't display on the "Configure" part of the GUI. I tried to log off and log in to refresh it but I can't see it..

I checked in the CLI and it's commited. Did I miss something or is there a something wrong ?

 

Best Regards,

John

Since it didn't display in GUI, I deleted it in CLI, commit and then tried to create it in GUI.

So now it display in GUI and CLI but the result is the same, it doesn't work : 

 

source NAT rule: 1 Rule-set: TEST-NAT
Rule-Id : 3
Rule position : 3
From zone : zone-source
To zone : zone-destination
Destination addresses : 0.0.0.0 - 255.255.255.255
Action : interface
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 0
Successful sessions : 0
Failed sessions : 0
Number of sessions : 0

 

Best Regards,

John

Hi John,

Traffic is not hitting the NAT rule, can you modify the rule like below.



delete security nat source rule-set TEST-NAT

set security nat source rule-set TEST-NAT from interface rethx.x ——> Interface connected to 172.20.x.y/24

set security nat source rule-set TEST-NAT to interface rethx.x ——> Interface connected to 78.x.y.z/32

set security nat source rule-set TEST-NAT rule 1 match destination-address 0.0.0.0/0

set security nat source rule-set TEST-NAT rule 1 then source-nat interface

commit

if this don’t help, can you share the “> show security flow session destination-prefix 78.x.y.z “ output after initiating ping from source?

Hi @rsuraj & @epaniagua,

 

Let's use real ip addresses for a clear view of the topology (still different from my topology). 

 

Private network 172.20.50.0/24 ----------- 172.20.50.254 reth1.50- Juniper - reth1.112 - 172.28.15.2/30 ------- 172.28.15.1 - Provider Side - 78.135.33.77/32

 

So I applied the changed you suggested @Rsuraj, it now display on the GUI after I commit in CLI. Still, I check with the command : ping 78.135.33.77 source 172.20.50.254 but it doesn't reply. 

 

Thank you for the debug flow command, I searched for something like that. Here the result :

Session ID: 34761, Policy name: self-traffic-policy/1, State: Active, Timeout: 8, Valid
In: 172.20.50.254/34257 --> 78.135.33.77/33435;udp, If: .local..0, Pkts: 1, Bytes: 40
Out: 78.135.33.77/33435 --> 172.20.50.254/34257;udp, If: reth1.112, Pkts: 0, Bytes: 0

 

Session ID: 44336, Policy name: self-traffic-policy/1, State: Active, Timeout: 14, Valid
In: 172.20.50.254/34257 --> 78.135.33.77/33436;udp, If: .local..0, Pkts: 1, Bytes: 40
Out: 78.135.33.77/33436 --> 172.20.50.254/34257;udp, If: reth1.112, Pkts: 0, Bytes: 0

 

Session ID: 96073, Policy name: self-traffic-policy/1, State: Active, Timeout: 4, Valid
In: 172.20.50.254/34257 --> 78.135.33.77/33434;udp, If: .local..0, Pkts: 1, Bytes: 40
Out: 78.135.33.77/33434 --> 172.20.50.254/34257;udp, If: reth1.112, Pkts: 0, Bytes: 0
Total sessions: 3

 

Isn't that because the flow is coming from the local interface when I do the test in CLI ? I'll try with a workstation or server on the private network side. I keep you updated.

 

Best Regards,

John

Thanks for the details, when you are sourcing the ping from SRX its taken as local traffic, to get this working you need the rule as below.


delete security nat source rule-set TEST-NAT

set security nat source rule-set TEST-NAT from zone junos-host

set security nat source rule-set TEST-NAT to interface reth1.112

set security nat source rule-set TEST-NAT rule 1 match destination-address 0.0.0.0/0

set security nat source rule-set TEST-NAT rule 1 then source-nat interface

commit

But for actual traffic from your client side to work we need the NAT shared earlier.

Hi @rsuraj @epaniagua

 

So it was that, you were right. Thank you for your help and all the infos.

 

Finaly I had a call with the provider. They added the route on their side to my private network. It's now working as it was requested before (without nat).

 

Have a nice weekend guys ! 

Br,

John

John,

 

I agree with Suraj. You can use the following source NAT rule for both types of traffic (Self-generated and from the 172.20.50.0/24 subnet):

 

set security nat source rule-set SOURCE-NAT from interface reth1.50
set security nat source rule-set SOURCE-NAT from junos-host
set security nat source rule-set SOURCE-NAT to interface reth1.112
set security nat source rule-set SOURCE-NAT rule 1 match destination-address 0.0.0.0/0
set security nat source rule-set SOURCE-NAT rule 1 then source-nat interface

 

 

As Suraj says, it looks like a routing-issue.....

 

What are the results of:

 

show route 172.28.x.2

 

The first ping is working because you have a route in place for that network (78.x.y.z) but you possibly don't have a route back to the 172.28.x.2 network

 

Can you also post your "show routing-options static"  output please?

 

 

Hi adgwytc,

 

Here the output :

 

> show route 172.28.x.2

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

172.28.x.2/32 *[Local/0] 22:58:41
Local via reth1.112

 

# show routing-options static

...
route 78.x.y.z/32 next-hop 172.28.x.1;

...

 

Best Regards,

John

Hi, John

 

Please confirm the following info in order to help you:

 

-Topology:

 

(172.20.x.y/24)-----L3_HOP-A------(172.28.x.2/30:reth1.112)-SRX-------(172.28.x.1)L3_HOP-B------------(78.x.y.z/32)
				                                zone-source     zone-destination

 

-You mentioned that you "changed the networks for confidentiality", but please confirm if the destination subnet is a private address and if the source subnet is a public address. This is in order to confirm if NAT is indeed needed or not.

 

-It looks like a route is missing on the destination host in order to send the reply traffic back to the SRX. Can you check it the destination host has a route back to 172.20.x.y/24? 

 

-You could also configure a firefwall-filter with a counter (for inbound direction) on the SRX interface that faces L3-HOP-B.  This way you can count the reply packets and if the counter increases then we can tell that the reply packets are reaching the SRX and from there we will continue with further troublehsooting. The filter will look like this:

 

1. Create the filter:

set firewall filter TEST term COUNTER from source-address 78.x.y.z/32
set firewall filter TEST term COUNTER from destination-address 172.20.x.y/24
set firewall filter TEST term COUNTER from protocol icmp
set firewall filter TEST term COUNTER then count REPLY-TRAFFIC
set firewall filter TEST term COUNTER then accept
set firewall filter TEST term ALLOW-THE-REST then accept

2. Apply the filter

set interfaces [INTERFACE] unit [UNIT] family inet filter input TEST

3. Commit the configuration, then try the ping and use the following command to check the counter:

user@host> show firewall all

Please let us know.