Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 28 subscribers
  • Views 12443 views
  • Users 0 members are here
Options
Suggested
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

Can't ping both ways in XG site-to-site VPN

Stephen Zuluaga

I've recently set up a site to site between two XGs using IPSec.

Problem

  • On the CLI of site A's XG, I can't ping site B's LAN interface.
  • On the CLI of site B's XG, I can ping site A's LAN interface.

Other Facts

  • Local service access for VPN zone is set to allow everything that is allowed for LAN zone. i.e. Ping, DNS, SSH, web admin, etc..
  • Each XG has a single firewall rule to allow the following connections
    • Source LAN & VPN zone any network/ip on any service
    • Destination LAN & VPN zone any network/ip
  • The remote and local LAN subnets are configured in the VPN settings on each XG.
  • The XGs are currently connected via a 1Gb ethernet switch on their WAN interfaces while I configure this new XG and get site-to-site working.
    • This switch has each XG's WAN port, and the PPPoE ADSL2+ bridge connected. No other devices on this switch.
    • Site A's XG is using PPPoE to get internet access
    • Site A has an additional IP address which it is using to connect to site B's WAN interface on.(their WAN interfaces are on a local LAN together)
      • This is while I sort out the config issues, then I will take site B's XG and local equipment to actual site across town.
    • Site B's XG is not doing any PPPoE because it is not at site yet.
      • Site B has no internet yet, but my focus is on getting site-to-site working.

I've tried to look in all the config areas that I can think of as being important but I'm stuck.

 

Can anyone suggest areas in either's config that I should be looking closer at? I have obviously missed something given I'm getting one way functionality, I just can't pick it.

 

I'm also wondering if/how I can turn on logging for default deny firewall rules, as that might help me understand more about if/how this is a firewall config issue.

 

Thanks for any potentially helpful thoughts.

 

Cheers,

Stephen



This thread was automatically locked due to age.
Parents
  • 0

    Hey Stephen,

    Have you tried testing using other services over the VPN tunnel? RDP or FTP to a resource across the VPN tunnel?

    What are you able to observe via the GUI packet capture for this attempted (ping) traffic from Site A to Site B? How about for Site B to Site A?

    On the CLI of Site A, what path is taken when it tries to ping Site B (Tracert)?

    Also note that by default, denied traffic should appear in your firewall logs. Traffic that does not match any existing firewall rules will be denied due to the implicit default drop rule 0.

    Regards,

  • 0 in reply to FloSupport

    Hi FloSupport

     

    Thanks for your suggestions, they helped me find a few interesting things:

    • I found denied connection from a host on Site A trying to access the Site B XG's LAN interface on it's normal 4444 port being denied with this message "Invalid TCP state."
    • traceroute from the CLI of each XG to the others' LAN interface yields blanks at each hop
    • I can Site A's XG allowing the pings through tun0, but I can't see any evidence of them on Site B's XG in accept or drop/reject

    Any thoughts?

    Cheers,

    Stephen

  • +1 in reply to Stephen Zuluaga

    --UPDATE--

    I wondered about whether tun0 pertains to SSL or IPSec, I think it's only SSL

     

    I had a disabled SSL site-to-site config where Site A was the server and Site B was the client, even though both ends were disabled I think that was the source of this issue.

    The Site A XG was routing traffic to the inactive tun0 interface, after I deleted the config, the issue resolved and now I'm able to access Site B from Site A.

     

    Is this a bug whereby an inactive SSL site-to-site config creates an active routing entry to that disabled tun0 interface?

Reply
  • +1 in reply to Stephen Zuluaga

    --UPDATE--

    I wondered about whether tun0 pertains to SSL or IPSec, I think it's only SSL

     

    I had a disabled SSL site-to-site config where Site A was the server and Site B was the client, even though both ends were disabled I think that was the source of this issue.

    The Site A XG was routing traffic to the inactive tun0 interface, after I deleted the config, the issue resolved and now I'm able to access Site B from Site A.

     

    Is this a bug whereby an inactive SSL site-to-site config creates an active routing entry to that disabled tun0 interface?

Children