Screen OS

Hi all,

I have the problem with VPN site2site, the Tunnel is already UP but i can't reachable to the LAN of site

My topology 

PC -- Switch Core -- SSG520 --(Internet) -- remote site

Between Switch Core and SSG520 i was using OSPF. On the SSG520 i make a static route of remote site 10.2.0.0/16 via tunnel.3 and redistribute into OSPF, on the switch Core already got route 10.2.0.0/16

S3560_OFFICE_F2#sh ip route 10.2.0.0
Routing entry for 10.2.0.0/16
Known via "ospf 1", distance 110, metric 2, type extern 1
Last update from 10.121.0.246 on GigabitEthernet0/48, 13:15:45 ago
Routing Descriptor Blocks:
* 10.121.0.246, from 10.121.0.1, 13:15:45 ago, via GigabitEthernet0/48
Route metric is 2, traffic share count is 1

But when i make a tracert on PC, the traffic be drop at gateway on Core Switch

C:\>tracert 10.2.0.3

Tracing route to 10.2.0.3 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 10.121.124.62
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.

I also make a policy from Zone Office --> Untrust and Untrust --> Office. I try to get log on policy SSG520 but nothing aprear

Thanks for help, any information you need just let me know

Regards,

Khanh Dang

Hi,

Please post the output from:

get route

get int tun.3

Are Office and Untrust interfaces mapped to different VRs?

Hi,

Please check the following output

SI_SSG520M_FW:SSG520(M)-> get route | in tun.3
* 233 10.2.0.0/16 tun.3 0.0.0.0 S 20 1 Root
* 275 192.168.133.0/24 tun.3 0.0.0.0 S 20 1 Root
* 497 192.168.131.0/24 tun.3 0.0.0.0 S 20 1 Root
* 236 192.168.182.0/24 tun.3 0.0.0.0 S 20 1 Root
* 498 192.168.181.0/24 tun.3 0.0.0.0 S 20 1 Root
* 234 192.168.176.0/24 tun.3 0.0.0.0 S 20 1 Root
* 495 192.168.188.0/24 tun.3 0.0.0.0 S 20 1 Root
* 237 10.58.0.0/16 tun.3 0.0.0.0 S 20 1 Root
* 499 10.56.0.0/16 tun.3 0.0.0.0 S 20 1 Root
* 240 192.168.164.0/24 tun.3 0.0.0.0 S 20 1 Root
* 467 10.57.0.0/16 tun.3 0.0.0.0 S 20 1 Root
* 461 192.168.174.192/26 tun.3 0.0.0.0 S 20 1 Root
* 500 192.168.174.0/24 tun.3 0.0.0.0 S 20 1 Root
* 241 10.48.0.0/16 tun.3 0.0.0.0 S 20 1 Root
* 377 192.168.173.0/24 tun.3 0.0.0.0 S 20 1 Root
* 494 192.168.169.0/24 tun.3 0.0.0.0 S 20 1 Root
* 238 192.168.228.0/24 tun.3 0.0.0.0 S 20 1 Root
* 519 10.60.34.0/24 tun.3 0.0.0.0 S 20 1 Root

DCN_SI_SSG520M_FW:SSG520(M)-> get interface tun.3
Interface tunnel.3(VSI):
description tunnel.3
number 20, if_info 655224, if_index 3, mode route
link up, admin status up
vsys Root, zone Untrust, vr trust-vr, vsd 0
admin mtu 0, operating mtu 1500, default mtu 1500
*ip 0.0.0.0/0 unnumbered, source interface ethernet0/1.100
*manage ip 0.0.0.0
bound vpn:
VTP_TO_VTN

Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
U 203.113.136.9 0x00000016 VTP_TO_VTN

pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled

OSPF disabled OSPFv3 disabled BGP disabled RIP disabled RIPng disabled
mtrace disabled
PIM: not configured IGMP not configured
MLD not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps

The Zone OFFICE and UNTRUST mapped to the same "trust-vr"

Thanks

Khanh Dang

Hi,

I also enclose the configure file on my SSG520

Regards

Khanh Dang

Hi,

The tunnel interfaces are located in Untrust zone but their parent inerface is ethernet0/1.100 which is located in Trust zone. You should move the tunnel interfaces to eth0/0 because eth0/0 terminates the VPN and is the Untrust interface.

Hi,

I already change as your recommend, but still happen

SI_SSG520M_FW:SSG520(M)-> get interface tun.3
Interface tunnel.3(VSI):
description tunnel.3
number 20, if_info 655224, if_index 3, mode route
link up, admin status up
vsys Root, zone Untrust, vr trust-vr, vsd 0
admin mtu 0, operating mtu 1500, default mtu 1500
*ip 0.0.0.0/0 unnumbered, source interface ethernet0/0
*manage ip 0.0.0.0
bound vpn:
VTP_TO_VTN

Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
U 203.113.136.9 0x00000016 VTP_TO_VTN

pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled

OSPF disabled OSPFv3 disabled BGP disabled RIP disabled RIPng disabled
mtrace disabled
PIM: not configured IGMP not configured
MLD not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps

C:\>tracert 10.2.0.3

Tracing route to 10.2.0.3 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 10.121.124.62
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.

Regards

Khanh Dang

Hi,

Try this:

ping 10.2.0.3 from eth0/3

Do you get a responce? Are there policy hits?

Hi,

SI_SSG520M_FW:SSG520(M)-> ping 10.2.0.3 from eth0/3
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 10.2.0.3, timeout is 1 seconds from ethernet0/3
.....
Success Rate is 0 percent (0/5)

The policy already enable, but no log aprear

Hi,

Do you think the problem on SW Core? Because the tracert result drop at SW Core

C:\Users\user>tracert 10.2.0.3

Tracing route to 10.2.0.3 over a maximum of 30 hops

1 8 ms 2 ms <1 ms 10.121.124.62
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.

Regards

Hi,

Yes, I have supposed this. But if you cannot ping directly from eth0/3 the problem is somewhere on SSG.

Try this:

undebug all

clear db

set ffilt src-ip 10.121.0.246

debug flow basic

ping 10.2.0.3 from eth0/3

undebug all

unset ffilt

get db stream

Please attach the output to your posting.

Hi,

Please check my attach file, just follow your guide!

Regards

Khanh Dang

Attachment(s)

FWSSG520 log.txt   42 KB 1 version

Hi,

The keywords are NHTB entry search not found in the debug output. This is strange because the active dynamic NHTB entry on tun.3 is correct and you have only one VPN mapped to tun.3. The reason may be a bug. The first ScreenOS releases contain multiple VPN-related bugs.

Try to configure a static NHTB entry on tun.3. You can use GUI for this or this command:

set int tun.3 nhtb 203.113.136.9 vpn VTP_TO_VTN

Also replace the route set route 10.2.0.0/16 interface tunnel.3 with this one:

set route 10.2.0.0/16 interface tunnel.3 gate 203.113.136.9

Static NHTB entries and tunnel routes with an explicit gateway IP are required if multiple VPNs are mapped to a single tunnel interface or if the remote GW is not a SSG.

I recommend to always use the static NHTBs and do not rely on the dynamically generated ones.

Hi,

Still not success, headache

DCN_SI_SSG520M_FW:SSG520(M)-> get interface tun.3
Interface tunnel.3(VSI):
description tunnel.3
number 20, if_info 655224, if_index 3, mode route
link up, admin status up
vsys Root, zone Untrust, vr trust-vr, vsd 0
admin mtu 0, operating mtu 1500, default mtu 1500
*ip 0.0.0.0/0 unnumbered, source interface ethernet0/0
*manage ip 0.0.0.0
bound vpn:
VTP_TO_VTN

Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
S U 203.113.136.9 0x00000016 VTP_TO_VTN

pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled

OSPF disabled OSPFv3 disabled BGP disabled RIP disabled RIPng disabled
mtrace disabled
PIM: not configured IGMP not configured
MLD not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps

Regards

Khanh Dang

Attachment(s)

FWSSG520 log_01.txt   33 KB 1 version

Hi,

What release is this?

The NHTB lookup is OK.

NHTB entry search found: vpn VTP_TO_VTN tif tunnel.3 nexthop 203.113.136.9 tunnelid 0x16, flag 0x0, status 4

The tunnel ID0x16  is correct, but, suddenly:

  matched tunnel-id <0x00000000>
  packet dropped, no way(tunnel) out

The Proxy ID check may also be a reason for this drops. I assume that the remote GW is also a SSG because you have configured a proxy ID containing the public IPs only. Disable the proxy ID check and remove the proxy ID.

Hi

I think it is OK now

C:\Users\user>tracert -d 10.2.0.30

Tracing route to 10.2.0.30 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 10.121.124.62
2 <1 ms <1 ms <1 ms 10.121.0.246
3 315 ms 315 ms 315 ms 203.113.136.9
4 317 ms 324 ms 318 ms 10.57.248.173
5 317 ms 318 ms 321 ms 10.57.248.50
6 318 ms 328 ms 317 ms 192.168.190.77
7 318 ms 318 ms 318 ms 10.56.248.74
8 * * * Request timed out.
9 * ^C

Could you explain for me what case we have to enable Proxy-id check?

Thanks for support

Khanh Dang

Hi,

The Proxy-id is always required if you configure VPN to a none-Juniper firewall. Virtually all of them negotiate the Proxy-ids during the phase two. One can say that they use policy-based VPN and derive the Proxy-IDs from the access-lists, VPN-Policies etc. Juniper Firewalls, if no Proxy-IDs are configured, do also use a default Proxy-ID which is 0.0.0.0/0 to 0.0.0.0/0, protocol Any. This means that you can always add, remove and change the remote and local networks without any need to edit the VPN configuration. That's why the route based VPN is so flexible. Besides you can save a lot of resources. A single SA can transport any number of networks, while the policy based VPN needs a separate SA for each pair of the networks.

Thanks you for support me !

Regards

Khanh Dang