Screen OS

I have dozens of SSG5 / 20 / 140 / 320 / 550 devices deployed and have never had much difficulty getting them to talk to each other for site to site vpns.  I feel very comfortable with these configurations but I am stumped on this one.

The current problem is that I have a Comcast connection with dynamic ip and I want to connect to a ssg520 that has a static ip in the datacenter.

I have tried with both an SSG20 and an SSG5 and am getting the same results, so either I'm making the same mistake on both or there is something funky with this connection.

The default route is automatically getting created when the juniper gets its dynamic ip from comcast; it's a slash 22 which i haven't seen before but shouldn't be an issue.

I have created a very basic policy-based vpn, exactly the way I've done it many times in the past.  I see zero logs on the responder ssg520, and I also see zero events on the initiator ssg5 and ssg20.  It's as if they just aren't trying to negotiate the tunnel at all.  All other traffic seems fine.  I even went back and followed the juniper kb for this scenario and used their names just to make extra sure I wasn't fat-fingering a more complex passphrase or something, but I don't think that is the issue.  Perhaps it's something funky with the connected route on the dynamic ip side that is preventing my pings from being properly detected so it never initiates the tunnel?

Initiator config below:

unset key protection enable
set clock timezone 0
set vrouter trust-vr sharable
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
unset auto-route-export
exit
set alg appleichat enable
unset alg appleichat re-assembly enable
set alg sctp enable
set auth-server "Local" id 0
set auth-server "Local" server-name "Local"
set auth default auth server "Local"
set auth radius accounting port 1646
set admin name ""
set admin password ""
set admin auth web timeout 10
set admin auth dial-in timeout 3
set admin auth server "Local"
set admin format dos
set zone "Trust" vrouter "trust-vr"
set zone "Untrust" vrouter "trust-vr"
set zone "DMZ" vrouter "trust-vr"
set zone "VLAN" vrouter "trust-vr"
set zone "Untrust-Tun" vrouter "trust-vr"
set zone "Trust" tcp-rst
set zone "Untrust" block
unset zone "Untrust" tcp-rst
set zone "MGT" block
unset zone "V1-Trust" tcp-rst
unset zone "V1-Untrust" tcp-rst
set zone "DMZ" tcp-rst
unset zone "V1-DMZ" tcp-rst
unset zone "VLAN" tcp-rst
set zone "Untrust" screen tear-drop
set zone "Untrust" screen syn-flood
set zone "Untrust" screen ping-death
set zone "Untrust" screen ip-filter-src
set zone "Untrust" screen land
set zone "V1-Untrust" screen tear-drop
set zone "V1-Untrust" screen syn-flood
set zone "V1-Untrust" screen ping-death
set zone "V1-Untrust" screen ip-filter-src
set zone "V1-Untrust" screen land
set interface "bri0/0" zone "Untrust"
set interface "ethernet0/0" zone "Untrust"
set interface "ethernet0/1" zone "DMZ"
set interface "bgroup0" zone "Trust"
set interface bgroup0 port ethernet0/2
set interface bgroup0 port ethernet0/3
set interface bgroup0 port ethernet0/4
set interface bgroup0 port ethernet0/5
set interface bgroup0 port ethernet0/6
unset interface vlan1 ip
set interface ethernet0/0 ip 24.7.114.35/22
set interface ethernet0/0 route
set interface bgroup0 ip 192.168.170.1/24
set interface bgroup0 nat
unset interface vlan1 bypass-others-ipsec
unset interface vlan1 bypass-non-ip
set interface ethernet0/0 ip manageable
set interface bgroup0 ip manageable
set interface ethernet0/0 dhcp client enable
unset interface ethernet0/0 dhcp client settings update-dhcpserver
set interface bgroup0 dhcp server service
set interface bgroup0 dhcp server enable
set interface bgroup0 dhcp server option gateway 192.168.170.1
set interface bgroup0 dhcp server option netmask 255.255.255.0
set interface bgroup0 dhcp server option dns1 8.8.8.8
set interface bgroup0 dhcp server option dns2 8.8.4.4
set interface bgroup0 dhcp server ip 192.168.170.101 to 192.168.170.149
unset interface bgroup0 dhcp server config next-server-ip
unset interface bgroup0 dhcp server config updatable
set flow tcp-mss
unset flow no-tcp-seq-check
set flow tcp-syn-check
unset flow tcp-syn-bit-check
set flow reverse-route clear-text prefer
set flow reverse-route tunnel always
set pki authority default scep mode "auto"
set pki x509 default cert-path partial
set dns host dns1 8.8.8.8
set dns host dns2 8.8.4.4
set dns host dns3 0.0.0.0
set dns host schedule 06:28 interval 4
set address "Trust" "myLan" 192.168.170.0 255.255.255.0
set address "Untrust" "westVault" 172.16.52.0 255.255.255.0
set crypto-policy
exit
set ike gateway "westGW" address X.X.X.X Aggr local-id "siteb.netscreen.com" outgoing-interface "ethernet0/0" preshare "HHlsnGLeNbpXnjs9fdC4ZGIPA4nYW2egXw==" proposal "pre-g2-3des-sha"
set ike respond-bad-spi 1
set ike ikev2 ike-sa-soft-lifetime 60
unset ike ikeid-enumeration
unset ike dos-protection
unset ipsec access-session enable
set ipsec access-session maximum 5000
set ipsec access-session upper-threshold 0
set ipsec access-session lower-threshold 0
set ipsec access-session dead-p2-sa-timeout 0
unset ipsec access-session log-error
unset ipsec access-session info-exch-connected
unset ipsec access-session use-error-log
set vpn "westIKE" gateway "westGW" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set url protocol websense
exit
set policy id 3 from "Untrust" to "Trust"  "westVault" "myLan" "ANY" tunnel vpn "westIKE" id 0x1 pair-policy 2
set policy id 3
exit
set policy id 2 from "Trust" to "Untrust"  "myLan" "westVault" "ANY" tunnel vpn "westIKE" id 0x1 pair-policy 3
set policy id 2
exit
set policy id 1 from "Trust" to "Untrust"  "Any" "Any" "ANY" permit
set policy id 1
exit
set nsmgmt bulkcli reboot-timeout 60
set ssh version v2
set config lock timeout 5
unset license-key auto-update
set telnet client enable
set snmp port listen 161
set snmp port trap 162
set snmpv3 local-engine id "0169072007001755"
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
unset add-default-route
exit
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
exit

Hi,

From the configuration, appears to be a routing problem. Try adding a default route or a route for the 172.16.52.x network through the e0/0 inteface.

Regards,

Gokul

Since the eth0/0 gets its ip via dhcp from comcast, it creates a default route dynamically (connected route).  I have never had to create a manual route for a policy based vpn before, but will try it - although I don't expect it to do anything as eth0/0 won't actually be the route for this traffic - the tunnel will...

Hi Pesos,

In a policy based VPN, the VPN negotiation is initiated during policy lookup, which happens after route lookup. In your case, you need some route (validity does not matter, it has to point to Untrust I/F) that will instruct the firewall to pass this traffic from Trust to Untrust.

Only then the traffic will hit policy id 2 and trigger VPN negotiation. If you are sure that the default route has been populated successfully by DHCP server, you can try:

1. 'get route ip 172.16.52.1' ---> Confirm the route is pointing to e0/0

2. Enable VPN monitor and Rekey, which will initiate VPN negotiation even in the absence of any realtime traffic

3. Try to ping remote subnet with internal interface as source and check if that triggers VPN negotiation

Regards,

Gokul

Thanks Gokul, I went ahead and added a static route in but it made no difference.  Still not seeing any attempts in the logs.

Below are the results before and after removing my static route:

Remote Management Console
login: netscreen
password:
ssg5-isdn-> get route ip 172.16.52.1
 Dest for 172.16.52.1
-------------------------------------------------------------------------
------
trust-vr       : => 172.16.52.0/24 (id=7) via 24.7.112.1 (vr: trust-vr)
                    Interface ethernet0/0 , metric 1
ssg5-isdn-> get route ip 172.16.52.1
 Dest for 172.16.52.1
-------------------------------------------------------------------------
------
trust-vr       : => 0.0.0.0/0 (id=6) via 24.7.112.1 (vr: trust-vr)
                    Interface ethernet0/0 , metric 1
ssg5-isdn->

Pesos,

In that case, can you collect a debug?

Use the below commands:

set ff src-ip 192.168.170.1 dst-ip 172.16.52.1

set ff src-ip 172.16.52.1 dst-ip 92.168.170.1

clear db (This will clear all debug data that you might have captured already - use with caution)

debug flow basic

debug ike detail

ping 172.16.52.1 from bg0

Once pings fail:

>>Press Esc key<<

set console page 0

get db st

The debug log that gets printed will give a better idea.

Thank you again Gokul.

I get nothing:

Remote Management Console

login: netscreen

password:

ssg5-isdn-> set ff src-ip 192.168.170.1 dst-ip 172.16.52.1

filter added

ssg5-isdn-> set ff src-ip 172.16.52.1 dst-ip 192.168.170.1

filter added

ssg5-isdn-> clear db

ssg5-isdn-> debug flow basic

ssg5-isdn-> debug ike detail

ssg5-isdn->  All debug off

ssg5-isdn-> set console page 0

ssg5-isdn-> get db st

ssg5-isdn->

You are welcome Pesos,

I dont see the ping command (ping 172.16.52.1 from bg0) being issued. Please give it a try...this will generate ICMP packets towards remote LAN, with bg0 IP as the source IP.

The filters are configured to capture traffic from this IP to 172.16.52.1

Thanks Gokul - I was doing the ping part from my client, not the firewall - i misunderstood.

When I tried to ping 172.16.52.1 from the firewall, the tunnel immediately came up and I saw the events as expected.

So the question is, why can the firewall ping 172.16.52.1 from bg0, but my computer at 192.168.170.99 cannot?

That is good news Pesos...

This confirms that the routing and policies are good in your end as well as the remote side.

To look into this further, you need to confirm if the packets from your LAN to remote LAN even make it to the firewall. You can simply modify the filter shared earlier and perform another capture:

set ff src-ip 192.168.170.10 dst-ip 172.16.52.1

set ff src-ip 172.16.52.1 dst-ip 92.168.170.10

clear db (This will clear all debug data that you might have captured already - use with caution)

debug flow basic

***Ping  172.16.52.1 from 192.168.170.10 (or any LAN machine, modify the above filters accordingly)

Once pings fail:

>>Press Esc key<<

set console page 0

get db st

Yes I have confirmed it is working....

Yet the tunnel never kicked in until I tried to ping from the firewall itself.  Very weird.  When I have a chance I will repeat again after rebooting the firewall.

Thank you so much for your help!