Screen OS

I am trying to convert my route based VPNs coming from my HQ to a hub and spoke VPN setup with my branch offices. I am following the guide below. http://kb.juniper.net/kb/documents/public/VPN/routebasedhubandspokevpn_rev_1_3.pdf. I believe i followed the document correctly; however, my pings are not getting through. I did do a couple things different.

1. Instead of creating a "VPN" zone and blocking intra-zone traffic, i used Untrust.

2. Since these are already existing VPNs that i need to convert to a hub n spoke setup, i have proxy-ids setup and in the guide, they do not. Could this be my issue?

EDIT: I am using Juniper SSG20 and SSG5 to do this in screenOS 6+

Hi,

In unrust have you disabled intrazone blocking or created untrust to untrust policy to allow traffic?

Also, is the VPN and the traffic not flowing?

If VPN is up, please verify the routing and policies are in order in both directions.

Thanks.

Hardeep

No, i did not disable intra-zone traffic in Untrust.

I did create a Policy for Untrust -> Untrust Spoke 1 -> Spoke 2 and Spoke 2 -> Spoke 1.

Both VPNs are up between Hub and Spoke 1 / Spoke 2. They are working fine; however, Spoke 1 to Spoke 2 does not work. I do not see any policy hits in the log when i attempt a ping from Spoke 1 to Spoke 2.

Hi,

You can take a step by step approach.
Check if packets is seen on the spoke1 policy.
Then check on hub policy and then verify spoke policy.
If you dont even see it on spoke1 then possibly some routing is causing it to fail.
You can run a debug on the firewall to check it.

set the filter

set ff dst-ip ip-address

clear the buffer

clear db

start debug

debug flow basic

initiate traffic

srop debug

undebug all

read the buffer

get db st

Hope this helps.

Thanks.

Hardeep

Do you have a route on Spoke 1 for the spoke 2 subnet pointed at the VPN tunnel and likewise on Spoke 2?

Use get route for the other spoke subnet and confirm where the traffic is sent.

So i solved half of my problem. Spoke 2 can get to spoke 1 just fine. It turns out, i was pinging a device which had ping disabled, haha. Spoke 1 cannot get to Spoke 2 though. When doing the debug, it looks like it is successful. It selects Tunnel.1 and i can see if passing down the IP addresses but i can never get a response to devices i know should be giving one. Trace routes just die after the gateway.

get route returns the destination subnet is routed to tunnel 1. Policies are in place and working to the best of my knowledge; however, even with logging on, i do not see pings in the logs. This is true for both Spoke 2 -> Spoke 1 (working) and Spoke 1 -> Spoke 2.

If you can tell me how to output the db string to a text file, i can paste the results up here.

Hi,

For secureCRT, you can save the entire session to a text file.
It is available in File options.
Else, you can just copy/paste the output

Just to reiterate, we need the following policies on both spokes:

trust to untrust

untrust to trust

These should allow LANS of spoke 1 and 2 accordingly.

On Hub we need Untrust to untrust and allow both way LANs to communicate.

Thanks.
Hardeep

Hub -> 10.72.82.0 /24

Spoke1 -> 10.4.4.0 /24

Spoke2 -> 192.168.1.0 /24

HUB

Source: 192.168.1.0 /24 Destination: 10.4.4.0 /24 - permit any untrust to untrust

Source: 10.4.4.0 /24 Destination: 192.168.1.0 /24 - permit any untrust to untrust

Spoke1

Source: 192.168.1.0 /24 Destination: 10.4.4.0 /24 - permit any untrust to trust

Source: 10.72.82.0 /24 Destination: 10.4.4.0 /24 - permit any untrust to trust

Source: 10.4.4.0 /24 Destination: 192.168.1.0 /24 - permit any trust to untrust

Source: 10.4.4.0 /24 Destination: 10.72.82.0 /24 - permit any trust to untrust

Spoke2

Source: 10.72.82.0 /24 Destination: 192.168.1.0 /24 - permit any untrust to trust

Source: 10.4.4.0 /24 Destination: 192.168.1.0 /24 - permit any untrust to trust

Source: 192.168.1.0 /24 Destination: 10.72.82.0 /24 - permit any trust to untrust

Source: 192.168.1.0 /24 Destination: 10.4.4.0 /24 - permit any trust to untrust

ill post the db string in a bit.

Your policies look complete.  You will need to determine which of the three firewalls is losing the traffic and why.

Add log to all the policies from spoke 1 to spoke 2

Initiate the failed ping

Check the policy log on spoke 1 and confirm you see the timed out ping request.  If not, run the debug flow basic here.

Check the policy log on the hub and if not present the block is here so run debug flow on the hub.

Check the policy log on spoke 2 if this also has the timed out ping then there is some other delivery issue.  If the log is empty run debug flow basic here.

Thanks Spuluka, ill run the debugs and let you know what i find. I am switching over to fiber on the Spoke 1 in a few days and until then, my VPN is down so it will be a couple of days before i reply.

Ok so doing a debug from my Spoke, i can see that the traffic is going down the tunnel.1 as it should. Yay, its going to my hub.

Now when i try to do a debug on my hub, i am not seeing anything. I am not sure if i am setting my filters correctly though.

So i am trying to ping 192.168.1.110 from my 10.4.4.10 device. I have tried:

set ff src-ip 10.4.4.10 dst-ip 192.168.1.110

and

set ff dst-ip 192.168.1.110

but i am not seeing anything hit in my debug flow with those set. Not sure if i am using the correct IPs when on the hub or if there is relaly no traffic being passed there. I am definitely seeing the traffic on the Spoke pass down the VPN tunnel though.

Hi,

The encrypted packet when it hits the Hub will have public IP addresses of hub/spoke.

Also, add a filter with public ip addresses and try debug again.

Thanks.

Hardeep

So...?

set ff src-ip Spoke 2 dst-ip Spoke 1

or

set ff src-ip Spoke 2 dst-ip hub

and

set ff src-ip Hub dst-ip Spoke 1

I have a ton of chatter on these VPN connections so i am trying to filter it to just src and dst or else i will see a ton of non relevant packets.

Ok so i finally found the packets i needed.

Neat issue though.

"Policy id (320000)

Packet dropped, denied by policy"

Issue being, there is no policy id 32..... i checked both in the gui and in the CLI.

Edit: Nevermind, looks like policy 320000 is a general deny rule built in. Not sure why i am hitting this but im looking around.

Edit2: Pinging from the Spoke to the other spoke which is working correctly, i can see that it hits Policy 1 which is Trust to Untrust any any any permit. So i have no idea why one spoke doesnt hit Policy 1 when the hub trys to route the traffic but the other spoke does hit policy 1 just fine.

Edit3: Comparing the debug flow of the working route to the not working route i see 1 difference.

Working route before it does its policy search, it is looking for Zone 2(trust) -> Zone 1(untrust). The one that is not working, before it does its policy search its looking for Zone1(untrust) -> Zone2(trust). Not sure why these would be backwards to each other, they are setup the same way. Anyways, thats why one route finds Policy 1 and the other hits the general built in deny rule

Hi,

This is good information.
Can you check if both the tunnel interfaces on the HUB terminate on the Untrust zone.
It is possible that for working scenario, the tunnel interface is on the trust zone itself, so now to reach the other spoke, the lookup is from trust to untrust. It is also possible that during debug for working scenario we were not able to capture the packet when it was coming from untrust to trust. Having said that, for traffic going from spoke to spoke (via the hub),  I dont see a reason for it to go to the trust zone of the hub (unless you desire it).

Generally this is how packe flow happens on Hub.
Both tunnel interfaces are in untrust zone (get interface tun.x can confirm this)
packets gets decrypted at the incoming tunnel interface in untrust zone.
Route lookup on hub will send traffic to another tunnel interface in untrust zone.
Policy lookup happens from untrust to untrust zone and the packet is sent to the destination spokie.

From previous posts I understand that you have untrust to untrust policies.
What about the routing? If you are comfortable in sharing the VPN specific config (including policies and routing) I can have a look.

Hope this helps.


Regards.
Hardeep

Sahota, i can share my config if you would like. I would prefer to send it via an email or something that doesnt leave it out on the internet.

Hmm: Results of my get interface (Tunnel.1 and Tunnel.4 are my Spokes. Seems like my interface zone is my issue. D'oh!)

Tunnel.1 - Zone Untrust

Tunnel.2 - Zone Untrust

Tunnel.3 - Zone Untrust

Tunnel.4 - Zone Trust

I am going to switch this and see if it fixes my issue.

WOOHOO! switching the tunnel interface from trust to untrust zone fixed all my issues. I really appreciate all of your help on this. Thanks!!!!

Is it possible to do the same thing with a route based client to site vpn? I use shrew soft vpn client.

Hi,

You mean client vpn acting as a spkoe, if yes, then it can work.

Thanks.

Hardeep

Know of any documentation? i havent found anything wtih google searchs. When i add the policys in the juniper to allow the VPN subnet access to the spokes and the network segments under the policy in shrewsoft, i cant connect to the VPN anymore.

KB15272 is the one with example of route based dial-up VPN.
In my opinion, policies should not cause any problem when establishng a route based vpn, atleast, the VPN should come up (even if traffic is not flowing)
Did you check the proxy-id settings.
Event logs should indicate the reason for VPN failure.

Thanks.
Hardeep

Found this while looking up that KB article you mentioned.

"If you're running ScreenOS 6.2 or lower, you'll need to either define a second dial-up VPN with 10.175.0.0/24 as the local proxy-id setting, or change to a policy-based VPN. If you're running ScreenOS 6.3, you can just add a second proxy-id pair to the existing VPN."

I am currently running netscreen 6.1. Sounds like i need to upgrade to 6.3 and then add another proxy-id to my route based dial up VPN. baaah.