SRX

Hi,

SRX-to-Zyxel scenario.

cannot get the traffic flow working over policy based vpn

vpn is up both IKE and IPSEC.

policy and reverse policy are configured.

when viewing statistics for ipsec ID, it shows "Encrypted" but no "Decrypted":

ESP Statistics:
  Encrypted bytes:            52740
  Decrypted bytes:                0
  Encrypted packets:            423
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

When pinging server on other side we can see "encrypted" incrementing 

we were troubleshooting this and tried to trace the traffic towards the server across the vpn but it went to the internet

we created source nat rule with "source nat off" and now it simply dies at firewall meaning it goes into the tunnel?!

anyway no ping response from the other side, which should be allowed.

checking the matching policy while pinging from srx side to Zyxel side.

run show security flow session destination-prefix 192.168.75.5/32
Session ID: 10408, Policy name: vpn-1/32, Timeout: 52, Valid
  In: 192.168.1.190/476 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/476;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 16269, Policy name: vpn-1/32, Timeout: 38, Valid
  In: 192.168.1.190/473 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/473;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 35130, Policy name: vpn-1/32, Timeout: 58, Valid
  In: 192.168.1.190/477 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/477;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Dont really know what to check next guys,

any help would be appreciated.

PS:

forgot to mention version

Model: srx240h2
JUNOS Software Release [12.1X46-D25.7]

Maybe you should share the configuration.

Hi,

sorry I'm not really sure which configuration you would like to see.(see attachment for the configuration)

the Phase 1 and 2 are set up like in book.

forward and reverse policies are set up with tunnel as action

we have configured "source nat OFF" for destination against the resources on the other side of the vpn.

and we have source nat interface rule as second rule.

the only one thing I'm kind of worring about is that we have to limit the communication between the systems on each side of the vpn.

We need to open for certain IPs across the vpn.

on srx side there is 1 server with 4 network cards, so we need to open traffic from all of these

and on the zyxel side there is 1 IP-address which needs to communicate with these 4 IPs.

As I know local and remote ID are derived from forward/reverse policy and are overwritten by it even if confiured under IKE. But that should not matter as tunnel is UP anyway?

Server-IPs is a address-set with 4 individual "adresses" containing 4 IPs for the local system.

We dont have control over remote firewall systems but I have seen some screenshots of the configuration applied.

Im not familiar with Zyxels way to configure VPN

Attachment(s)

juniper-sani.txt   3 KB 1 version

I assume you shared the configuration for the local VPN gateway.

On this VPN gateway you need to make sure that you have a route to 192.168.75.5/32 that egresses on ge-0/0/0.0

I believe you have it as you can see the counter for encrypted packets increasing.

Similarly on the remote peer you need to have a route to 192.168.1.187-190 that egresses your untrust interface. Maybe this route is missing.

Hi,

I dont believe you the route is needed as this is policy-based vpn and not route based one.

am I mistaken?

Hi dan_b,

Yes the route is required. Otherwise how would the remote peer know where to send the return traffic?

--
If this post solves your problem, please mark this post as "Accepted Solution".
Kudos are appreciated

I confirmed your posted cnfiguration is indeed a policy based VPN so you do NOT need a route installed for this to work correctly.  Furthermore your first posting shows that the policy is being hit correctly and packets are being encrypted and sent down the tunnel interface.

You have successfully verified all configurations on a Policy based VPN where the tunnel is up but traffic is not working as per this kb article.

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

I am pretty sure the configuration issue will be on the other side device not returning the traffic to the tunnel back to the SRX.

So this is the scenario:

local host - local VPN gateway - ge-0/0/0.0 -------------- interface X - remote VPN gateway - remote host

localhost IP = 192.168.1.190
remote IP = 192.168.75.5


As I explained in my previous post, on the local VPN gateway, you need a route that tells that you can reach 192.168.75.5 through the interface ge-0/0/0.0
I repeat: I believe you have such a route as you can see the counter for encrypted packets increasing. This is why the local gateway knows that the traffic sent to the zone untrust and this is we match the security policy "vpn-trust-1" that will send IP packet over the IPsec VPN "ike-vpn"

For traffic initiated on the remote gateway, the traffic hits the remote VPN gateway which then needs to route the traffic destined to 192.168.1.190.
On that remote gateway you need to run : "show route 192.168.1.190". The next-hop must be the interface X. If such a route is not present, how does the remote gateway knows how to route the traffic?
"I am pretty sure the configuration issue will be on the other side device not returning the traffic to the tunnel back to the SRX." I totally agree. This is why I asked to checked the routing on the remote gateway.

Also did you check that there is no asymmetric routing? Is the remote host sending traffic back the remote VPN gateway? and via the same incoming security zone?
Can you see the session on the remote gateway? Do you see the return traffic?
Can you run a packet capture on the remote host? Do you see the incoming ping?

Sorry Pantunes, but you are incorrect.  Policy based VPN do NOT require a route to the remote LAN subnet.  This is only needed for a route based vpn.

See the Policy based VPN configuration sample

set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24
set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30
set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
set security zones security-zone untrust interfaces ge-0/0/3.0
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone trust interfaces ge-0/0/0.0
set security zones security-zone trust host-inbound-traffic system-services all
set security address-book book1 address sunnyvale 10.10.10.0/24
set security address-book book1 attach zone trust
set security address-book book2 address chicago 192.168.168.0/24
set security address-book book2 attach zone untrust

Read more at http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-policy-based-vpn-configuring.html#wXtlZkUH4YUYKtbW.99

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-policy-based-vpn-configuring.html

Versus the route based VPN sample

set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24
set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30
set interfaces st0 unit 0 family inet address 10.11.11.10/24
set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
set routing-options static route 192.168.168.0/24 next-hop st0.0
set security zones security-zone untrust interfaces ge-0/0/3.0
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone trust interfaces ge-0/0/0.0
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone vpn-chicago interfaces st0.0
set security address-book book1 address sunnyvale 10.10.10.0/24
set security address-book book1 attach zone trust
set security address-book book2 address chicago 192.168.168.0/24
set security address-book book2 attach zone vpn-chicago

Read more at http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-route-based-vpn-configuring.html#gV4QglFl7UWyytGs.99

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-route-based-vpn-configuring.html

On this particular case, you can see from the first post that we have valid sessions setup for pings from the SRX to the remote site:

run show security flow session destination-prefix 192.168.75.5/32
Session ID: 10408, Policy name: vpn-1/32, Timeout: 52, Valid
  In: 192.168.1.190/476 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/476;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 16269, Policy name: vpn-1/32, Timeout: 38, Valid
  In: 192.168.1.190/473 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/473;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 35130, Policy name: vpn-1/32, Timeout: 58, Valid
  In: 192.168.1.190/477 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60
  Out: 192.168.75.5/1 --> 192.168.1.190/477;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

And we have packet counts that encrypt onto the VPN tunnel at the SRX side.

ESP Statistics:
  Encrypted bytes:            52740
  Decrypted bytes:                0
  Encrypted packets:            423
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

These are exactly the testing recommended by kb10093 to verify the configurations on the SRX when you have a Policy based VPN that is up but traffic is not passing.

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

Further testing needs to be done on the remote side to confirm what happens to those packets sent down the tunnel and why the return traffic is not being sent back to the SRX.  These tests verify the the SRX side configuration is correct and working.

Hi spuluka,

Your link shows that such a route IS required. In your the example given this would be the route below which is mateched when you need to send traffic over the VPN:

set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1

Anyway as I said, on the local VPN gateway all these settings (policy, routing) seem OK. What I would like to see now is the configuration on the remote VPN gateway and the output of  show security flow session as well when the ping is initiated on the local site. We need to make sure that the remove VPN receives the traffic, and if it does, that it also receives the return traffic.

Pantunes,

That is a standard default route out of the device to the internet and not related at all to the VPN configuration.  If that route were missing the VPN tunnel would not be up at all as the gateway would not be reachable.

Route based vpn need a route to the tunnel interface as part of the VPN configuration.

set routing-options static route 192.168.168.0/24 next-hop st0.0

This is not required for Policy based VPN.

Yes, I think all the testing done here shows the next place to look is the VPN configuration on the remote side for the Zyxel firewall.  From what I see in searches some models require route and policy configurations to use tunnels and others have a fully integrated wizard setup.  Which model is in use for this connection?

Hi spuluka,

Yes this route is also used to reach the internet, it will certainly be used to reach the remote VPN gateway. But it is also used when the local gateway receives the first packet of a flow destined to the remote subnets. By remote subnets I mean the subnets reachable via the IPsec VPN.

When the local VPN gateway receives the first packet of a flow destined to the remote subnet, it will

1) Do a route a lookup to find the egress security zone.

2) Thanks to this route, it will know that the egress security zone is "untrust".

3) Then it can check the security policies "from-zone Z to-zone untrust"

4) It finds the policy allowing such traffic via the IPsec tunnel "then permit tunnel pair-policy vpn-untrust-1"

If point 2) fails, then the SRX cannot chek points 3) and 4)

Check this post that states exactly what I am trying tio explain

http://forums.juniper.net/t5/SRX-Services-Gateway/Policy-Based-VPN-traffic-fails-with-quot-no-route-quot-error-if/td-p/76440#swAtYdkhWH07blgI.97

On the opposite direction, something equivalent is necessary but only for traffic initiated remotely.

And this is because if the traffic is initiated locally, the return packet that hits the remote SRX will not require a route lookup as there is already a session for the flow. The only requirement is that the return traffic hits the remote SRX on the same security zone as the initial packet left it.

Coming back to the initial problem, I beleive we need to troubleshoot on the remote peer.

Hi all,

after further testing with personell on the peer side, we finally solved it.

We tested differenet proposals and policy-object and finally another server on the peer-side.

Finally traffic flew as intended both encrypted and decrypted.

Thanks for all your suggestions.

Is "policy vpn-trust-1" the only security policy in "from-zone trust to-zone untrust"? If no place it at the top(use the insert command)
Is "policy vpn-untrust-1" the only security policy in "from-zone untrust to-zone trust"? If no place it at the top
From the srx ping 192.168.75.5 interface ge-0/0/0.0 to see if you even get a response
Add this statement, (can be done temporarily)
#set security flow tcp-mss ipsec-vpn mss 1350
#set security ipsec traceoptions flag packet-drops
can you configure traceoptions with flag basic-datapath?

Hello ,

As per the output is shared  , the traffic from SRx end is going into the tunnel , thats why it shows the encrypt packet getting incremented .  Also the session details shows that same .

But we are not getting any decrypt packet on SRX which shows that we are not getting reverse packet from the peer Zyxel  .

Now there are 2 possibilitied for this :

1)  The peer device is not getting our VPN packet  : In this case you need to check if the peer device if you are getting or not . If its confirmed that the peer device is not getting the VPN packet , it could be the ISP dropping the packet .

2)  The peer device gets the VPN traffic from SRX , but dropping the reverse packet  : In this case you will see the decrypt packet counter increamenting  on peer end but no encrypt packet .  So you need to look into the peer device to see why its dropping the reverse packet .

Now one more thing you need to keep in mind is that  in SRX policy based VPN does not support NAT from VPN traffic , so you need to always keep NAT off for VPN traffic . If you need to use  NAT for VPN , you may need to switch the setup to "route based VPN "  .