This article describes the issue of a customer being unable to access the internet, via policy based VPN, from the branch office to the headquarters.

Here is the customer topology:

                   1.1.1.1    1.1.1.2
                         PC1 PC2
                           | |
                         Firewall (ipsec vpn peer in branch office)
                               |
                          200.200.200.1
                               |
                          Internet
                               |
                          Internet
                          |       |
  100.100.100.100      101.101.101.101
                             | |
                       eth3 eth4 Untrust
                             | |
                      ScreenOS( firewall in headquarter)
                          eth1 Trust


The firewall in the branch office has 2 VPN lines to headquarters; VPN1 is established with ScreenOS eth3 and VPN2 is established with ScreenOS eth4. In the headquarters, the internet access passes only through the eth3 interface. Customer wants PC1 in branch office to access internet via VPN1 and PC2 through VPN2 to headquarters and then access internet by eth3.

Here are the policies from ipsec vpn and internet access:

set policy id 232 from "Untrust" to "Trust" "1.1.1.1/32" "any" "ANY" tunnel vpn "vpn1" < for pc1 vpn incoming
set policy id 169 from "Untrust" to "Trust" "1.1.1.2/32" any" "ANY" tunnel vpn "vpn2" < for pc2 vpn incoming
set policy id 1 from "Trust" to "Untrust" "Any" "Any" "any" nat src permit  < for pc1 and pc2 internet access

After all the VPNs are active, the customer finds that PC1 is able to successfully access the internet and PC2 fails to access the internet.

The root cause is that the incoming VPN interface for VPN2 is different from the interface, via which PC2 accesses the internet. The incoming VPN2 interface is eth4 and the internet access interface is eth3. When they are different, ScreenOS will not think that it is a Hub-spoke VPN scenario. Here is the debug flow basic for PC2:

search route to (ethernet4, 1.1.1.2->74.125.71.99) in vr untrust-vr for vs
-0/flag-0/ifp-null
[ Dest] 30.route 74.125.71.99->100.100.100.1, to ethernet3
routed (x_dst_ip 74.125.71.99) from ethernet4 (ethernet4 in 0) to ethernet3
policy search from zone 1-> zone 1 < access internet from untrust to untrust
policy_flow_search policy search nat_crt from zone 1-> zone 1
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 74.125.71.99, port 63179, proto 1)
policy_flow_search in tunnel pak_ptr policy: id: 232, from zone 1 -> 2 < vpn incoming from untrust to trust, ScreenOS finds it is differenet from internet access, packet drops
No policy matched for tunnel traffic, logging for:
VPN policy= 232: szone 1 dzone 1 pid 232 ports 800f6cb iphdr c7d6f910
log this session (pid=232)

Here is the vpn1 debug:
****** 1786295.0: <Untrust/ethernet3> packet received [144]******
ipid = 18729(4929), @c7d5c910
packet passed sanity check.
ethernet3:200.200.200.1/16354->100.100.100.100/34047,50<Root>
existing session found. sess token 30
flow got session.
flow session id 31956
flow_decrypt: 2fde988(3), flow_decrypt: 2fde988(3)dec vector=d78160.
IPv4 encrypted pak.
Dec: SPI = 3fe284ff, Data Len = 144
SA tunnel id=0x0000006d, flag<000021a3>
chip info: PIO. Tunnel id 0000006d
ipsec decrypt prepare done
ipsec decrypt set engine done
ipsec decrypt engine released, auth check pass!
packet is decrypted
ipsec decrypt done
ethernet3:1.1.1.1/1554->74.125.71.99/2,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet3>, out <N/A>
[ Dest] 30.route 1.1.1.1->100.100.100.1, to ethernet3
flow_first_routing: in <ethernet3>, out <N/A>
search route to (ethernet3, 1.1.1.1->74.125.71.99) in vr untrust-vr for
vsd-0/flag-0/ifp-null
[ Dest] 30.route 74.125.71.99->100.100.100.1, to ethernet3
routed (x_dst_ip 74.125.71.99) from ethernet3 (ethernet3 in 0) to ethernet3
hub-and-spoke packet, need loopback <-----internet access interface is as same as incoming vpn interface, ScreenOS thinks hub-spoke and add virtual loopback int
policy search from zone 1-> zone 2 <-----access internet net from untrust to trust same as vpn incoming
policy_flow_search policy search nat_crt from zone 1-> zone 2
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 74.125.71.99, port 61931, proto 1)
policy_flow_search in tunnel pak_ptr policy: id: 169, from zone 1 -> 2 < vpn incoming from untrust to trust, match policy id 169
VPN policy= 169: szone 1 dzone 2 pid 169 ports 800f1eb iphdr c7d5c910
Permitted by policy 169
No src xlate choose interface ethernet1 as outgoing phy if
check nsrp pak fwd: in_tun=0x4000006d, VSD 0 for out ifp ethernet1
no loop on ifp ethernet1.
session application type 0, name None, nas_id 0, timeout 60sec
service lookup identified service 0.
flow_first_final_check: in <ethernet3>, out <ethernet1>
existing vector list 25-4207f60.
Session (id:31712) created for first pak 25
loopback session processing
post addr xlation: 1.1.1.1->74.125.71.99.
flow_first_sanity_check: in <ethernet1>, out <N/A>
chose interface ethernet1 as incoming nat if.
flow_first_routing: in <ethernet1>, out <N/A>
search route to (ethernet1, 1.1.1.1->74.125.71.99) in vr trust-vr for vs
d-0/flag-0/ifp-null
[ Dest] 30.route 74.125.71.99->100.100.100.1, to ethernet3
routed (x_dst_ip 74.125.71.99) from ethernet1 (ethernet1 in 0) to ethernet3
policy search from zone 2-> zone 1
policy_flow_search policy search nat_crt from zone 2-> zone 1
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 74.125.71.99, port 61931, proto 1)
No SW RPC rule match, search HW rule
Permitted by policy 1
dip id = 2, 1.1.1.1/1554->100.100.100.100/8499
choose interface ethernet3 as outgoing phy if
check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet3
vsd 0 is active
no loop on ifp ethernet3.
session application type 0, name None, nas_id 0, timeout 60sec
service lookup identified service 0.
flow_first_final_check: in <ethernet1>, out <ethernet3>
existing vector list 21-4057fb0.
Session (id:31628) created for first pak 21
vector index1 25, vector index2 21
existing vector list 25-4207f60.
existing v6 vector list 25-40591b0.
new vector index 25.
existing vector list 21-4057fb0.
loopback session created
flow_first_install_session======>
route to 100.100.100.1
arp entry found for 100.100.100.1
nsp2 wing prepared, ready
nsrp msg sent.
flow got session.
flow session id 31712
vsd 0 is active
skipping pre-frag
no more encapping needed
flow_send_vector_, vid = 0, is_layer2_if=0
send packet to traffic shaping queue.
****** 1786295.0: <Untrust/ethernet3> packet received [60]******
ipid = 5153(1421), @c7d54910
packet passed sanity check.
ethernet3:200.200.200.1/41074->100.100.100.100/30340,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet3>, out <N/A>
[ Dest] 30.route 200.200.200.1->100.100.100.1, to ethernet3
existing vector list 20-42a6fa0.
create a self session (flag 0x206), timeout=60sec.
flow_first_install_session======>
make_nsp_ready_no_resolve()
search route to (self, 100.100.100.100->200.200.200.1) in vr untrust-vr for vs
d-0/flag-3000/ifp-ethernet3
[ Dest] 30.route 200.200.200.1->100.100.100.1, to ethernet3
route to 100.100.100.1
nsrp msg sent.
flow got session.
flow session id 31628
packet is for self, copy packet to self
copy packet to us.
****** 1786295.0: <Self/self> packet received [60]******
ipid = 16647(4107), @024aedf4
flow_self_vector2: send pack with current vid =0, enc_size:0
processing packet through normal path.
packet passed sanity check.
self:100.100.100.100/30340->200.200.200.1/41074,1(0/0)<Root>
Not IKE nor NAT-T nor ESP protocol.
existing session found. sess token 8
flow got session.
flow session id 31628
skip ttl adjust for packet from self.
existing vector list 20-42a6fa0.
flow_send_vector_, vid = 0, is_layer2_if=0
packet send out to 00e0fc5810b8 through ethernet3
## 2011-12-20 16:58:35 : NHTB entry search no found: vpn none tif tunnel.3 nexth
op 10.2.10.45

Policy based VPN is not recommended; route based VPN is recommended for this kind of scenario. In this scenario, the ScreenOS requests VPN incoming interface is the same as the internet access interface. So the solution is to add a route to ensure that PCs access the internet by using eth4.