New Member

Question

IPSEC - ONE WAY PING

Forum|Forum|1 year ago
November 4, 2024
10 replies
3825 views

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

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

IPsec

Toshi_Esumi

SuperUser

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

SuperUser

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

woodJTAuthor

New Member

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

arahman

Staff

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

woodJTAuthor

New Member

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

SuperUser

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

Sign up

Login with SSO

Login to the community

Login with SSO