IPSEC - ONE WAY PING

[woodJT]

Hi Fellows,

I have configured a simple ipsec tunnel hub to 1x spoke hoping to add more spokes later on.

the ipsec tunnel is dial up based with peertyp any . the tunnel is up and can ping the local subnet behind the hub from the remote subnet behind the spoke but not the opposite direction .

I assigned IP to the tunnel interfaces and I can ping only direction [spoke to hub but not hub to spoke]

I triple checked the static routes and firewall policies and all look fine. 

am I missing anything ?

SPOKE TO HUB PING

# execute ping 192.168.2.11
PING 192.168.2.11 (192.168.2.11): 56 data bytes
64 bytes from 192.168.2.11: icmp_seq=0 ttl=255 time=4.6 ms
64 bytes from 192.168.2.11: icmp_seq=1 ttl=255 time=4.4 ms
64 bytes from 192.168.2.11: icmp_seq=2 ttl=255 time=4.4 ms
^C
--- 192.168.2.11 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.4/4.4/4.6 ms

=====================

HUB TO SPOKE PING

====================

# execute ping 192.168.3.25
PING 192.168.3.25 (192.168.3.25): 56 data bytes
^C
--- 192.168.3.25 ping statistics ---
131 packets transmitted, 0 packets received, 100% packet loss

 ==================================

[Toshi_Esumi]

If ping from spoke to hub works, routing is working fine for both directions. Beside if you assign a tunnel interface ip, you must have forced to configure "remote-ip". Ping between them doesn't involve routing because those are /32 connected routes.
Did you enabling "ping" on the spoke tunnel interface? Check in CLI "show system interface <tunnel_Interface_name>". Should show up like "set allowaccess ping https ssh" if allowed.

Toshi

[Toshi_Esumi]

Or not. If it's a "dialup" or "dynamic". I need to see your phase1-interface config in CLI on both sides to determine that, under "config vpn ipsec phase1-interface".

Another possibility is NAT is enabled on the spoke side policy, IPsec-interface->LAN-interface.

Toshi

[woodJT]

ping is definitely enabled on the tunnel interfaces in both side and no NAT is off on 4 x firewall policies 

[Toshi_Esumi]

Then you have to do sniff and flow debug as @arahman is aking.
When you do that, you might need to disable ASIC offloading on the direction of policy. The command line is "set auto-asic-offload disable".
I would suggest sniffing on the tunnel-interface on the hub side first. I'm assuming it's going into the tunnel. Then you need to sniff on the spokeside. If you see it's coming in but no replies are going back to the tunnel, that's when I would run flow debug on the spoke side.

Toshi

[arahman]

HI, can you please take the sniffer and also the debug flow when doing the ping in the direction it is not working. Thanks

di sniffer packet any ' host <source ip> and host <destination ip>  and icmp ' 4 0 l

and also the debug flow

di de di

di de reset

di de flow show iprope en

di de flow show func en

di de flow filter addr <source ip addr> <destination ip addr> and

di de flow filter proto 1

di de flow trace start 300

di de en

[woodJT]

  id=65308 trace_id=1138 func=print_pkt_detail line=5795 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:2->192.168.2.1:2048) tun_id=0.                  0.0.0 from hub_Internal. type=8, code=0, id=2, seq=33541."

id=65308 trace_id=1138 func=resolve_ip_tuple_fast line=5883 msg="Find an existing session, id-000c4924, original direction"

id=65308 trace_id=1138 func=npu_handle_session44 line=1199 msg="Trying to offloading session from hub_Internal to to_spoke, skb.npu_flag=00000400 ses.s     tate=00000204 ses.npu_state=0x01040000"

id=65308 trace_id=1138 func=fw_forward_dirty_handler line=436 msg="state=00000204, state2=00000001, npu_state=01040000"

id=65308 trace_id=1138 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface to_spoke, tun_id=0.0.0.0"

id=65308 trace_id=1139 func=print_pkt_detail line=5795 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:2->192.168.2.1:2048) tun_id=0.0.0.0 from hub_Internal. type=8, code=0, id=2, seq=33542."

id=65308 trace_id=1139 func=resolve_ip_tuple_fast line=5883 msg="Find an existing session, id-000c4924, original direction"

id=65308 trace_id=1139 func=npu_handle_session44 line=1199 msg="Trying to offloading session from hub_Internal to to_spoke, skb.npu_flag=00000400 ses.s                  tate=00000204 ses.npu_state=0x01040000"

id=65308 trace_id=1139 func=fw_forward_dirty_handler line=436 msg="state=00000204, state2=00000001, npu_state=01040000"

id=65308 trace_id=1139 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface to_spoke, tun_id=0.0.0.0"

[Toshi_Esumi]

As you can see the packets to 192.168.2.1 and 192.205.236.1 went into the tunnel "to_spoke" in "original direction". But neither of them are 192.168.3.25, and more importantly no replies are coming back.

If those two subnets are supposed to be on the other side, you need to do the same on the other side FGT as I said before.

Toshi
Toshi

[Toshi_Esumi]

Wait a sec. With your original post 192.168.2.x was on HUB side. Why the packet to 192.168.2.1 goes into "to_spoke"?
Which FGT did you run this flow dedug?
What are the subnets on the HUB side and the spoke side?

And those are coming from "hub_internal". I'm assuming you took this at the HUB FGT, and it's a VLAN or other interface. Then the subnet doesn't match.

Toshi

[woodJT]

my bad, I had to change the config again as didnt the hardware available for me all the time for testing.

192.168.2.x is behind the spoke 

192.168.1.x is behind the hub

192.168.2.x pings 192.168.1.1 ( hub_internal is hub lan interface ) and 192.168.1.2 ( machine connected to hub lan interface)

and yes, hub_internal is configured as .1a with VLAN

"to_spoke" is the ipsec tunnel