This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

v18 - cannot ping to XG from route based VPN

Hi,

I'm trying out the XG v18 route based VPN. So far I've got it replacing the policy based VPN to Azure and between sites. What I've noticed is that since switching the VPN from policy to route, I'm unable to ping the XG from the other side of the tunnel. I can ping other devices so I know the tunnel is working, I just can't ping the XG's local IP from the remote tunnel. Pinging the XG's WAN IP works, however that would be cause of the local ACL exception. All XG are on SFOS 18.0.0 GA-Build354.

Thank you.

This thread was automatically locked due to age.

Parents

0 LuCar Toni over 4 years ago

The VTI is located in Zone VPN. Is Ping allowed for VPN?

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel
0 Wimar Aswan over 4 years ago in reply to LuCar Toni

Yes, ping is allowed on the XG on both sides.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 4 years ago in reply to Wimar Aswan

Which IP do you try to ping? And is XG able to find a route for this IP?

Check Diagnostic to find, if the XG1 is able to find a route to XG2.

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel
0 Wimar Aswan over 4 years ago in reply to LuCar Toni

The IP of PortA on one of the XG. If I do a route lookup in XG2 for XG1's PortA IP address, it returns saying it is located in PortB instead of the VTI interface. If I create a static route for XG1's local subnet, route lookup in XG2 will return with the VTI interface. However ping still doesn't work.

I've tried the following route precedence:

SD-WAN policy route, VPN route, Static route. (initial value as I upgraded to v18)

Static route, SD-WAN policy route, VPN route.

Both system generated traffic and reply packet routing have been enabled.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 4 years ago in reply to Wimar Aswan

Try to perform a Packet Capture and check, which site is dropping the Traffic.

CLI: Advanced Shell: drppkt | grep icmp

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel
0 Wimar Aswan over 4 years ago in reply to LuCar Toni

I've opened two SSH sessions to each XG and on one session, I run packet capture using that command. I did the ping test from the second SSH session. Unfortunately the packet capture didn't show any result from either XG.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 4 years ago in reply to Wimar Aswan

Could you show us the tcpdump of both appliance?

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 LuCar Toni over 4 years ago in reply to Wimar Aswan

Could you show us the tcpdump of both appliance?

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 Wimar Aswan over 4 years ago in reply to LuCar Toni

So it turns out the XG is trying to reply to the ping using the WAN port instead of the xfrm port. If I add a static route pointing to the remote XG xfrm port IP address, ping now works. Issue seems to be with the SD WAN policy then as I have to use static routes to make things work.

I followed the Sophos Support YouTube video to create the route based VPN and SD WAN policy. Slight change that I did was that I left the incoming interface blank and I added the SSL and Sophos Connect subnets of each XG in source and destination. I have tried removing this and making it the same as in the video, however the ping issue occurs without static routes.
Cancel
Vote Up 0 Vote Down

Cancel
0 Wimar Aswan over 4 years ago in reply to Wimar Aswan

Resolution was to set the source network to any so that it would include traffic generated from the firewall itself.
Cancel
Vote Up 0 Vote Down

Cancel