Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 5652 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

Issues with web-access after routing 0.0.0.0/0 over IPsec

garnser
Hi all,

We've started routing all our remote office traffic via our data-center using IPsec setting 0.0.0.0/0 as local network in our data-center and whatever IP-ranges used in the remote office as remote networks and vice versa on the other end.

After doing this we've started experiencing issues with web-traffic where we get timeouts and serious delays, running tests directly from the data-center doesn't show any of these issues so we're pretty certain that it's related to the IPsec tunnel. We're seeing the same issue with both Astaro VPN gateways in the remove offices and StrongSwan installations.

Please advice


This thread was automatically locked due to age.
Parents
  • 0
    Just gave it a run but no love

    Frustrating!  How about the Astaro log from when the connection is enabled, and the IPsec log from the other side for the same time?

    Also I'm curious as to whether the kernel could get a bit whiny since IPsec is acting like layer 2 forwarding all my local traffic over the tunnel even though my network technically is a part of the rightsubnet (0.0.0.0/0).

    I've read every post about VPNs here over the last 2+ years and have not seen anything like that.

    the linux-endpoint has a IPsec connection with leftsubnet=172.27.76.0/24, rightsubnet=0.0.0.0/0. As an affect clients on the 172.27.76.0/24 subnet is unable to access 172.27.76.1 as the VPN gateway forwards this to the astaro firewall bypassing Layer 2 (somehow).

    What does the route print look like on one of the clients experiencing that problem?  And, what do you mean by "unable to access 172.27.76.1?"

    Cheers - Bob
  • 0 in reply to BAlfson
    Frustrating!  How about the Astaro log from when the connection is enabled, and the IPsec log from the other side for the same time?

    I'll dig this up

    I've read every post about VPNs here over the last 2+ years and have not seen anything like that.

    I had a chat with the strongswan develops and got some tips which I'll try after hours.


    What does the route print look like on one of the clients experiencing that problem?  And, what do you mean by "unable to access 172.27.76.1?"


    Server:
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    212.112.163.92  0.0.0.0         255.255.255.252 U     0      0        0 eth0
    172.27.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
    0.0.0.0         212.112.163.93  0.0.0.0         UG    0      0        0 eth0

    Client:
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    172.27.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
    0.0.0.0         172.27.76.1  0.0.0.0         UG    0      0        0 eth0

    Unable to access as in all traffic from a 172.27.76.X client goes to /dev/null when it hits 172.27.76.1, no ping, ssh no nothing. If I kill the tunnel it works just fine.
Reply
  • 0 in reply to BAlfson
    Frustrating!  How about the Astaro log from when the connection is enabled, and the IPsec log from the other side for the same time?

    I'll dig this up

    I've read every post about VPNs here over the last 2+ years and have not seen anything like that.

    I had a chat with the strongswan develops and got some tips which I'll try after hours.


    What does the route print look like on one of the clients experiencing that problem?  And, what do you mean by "unable to access 172.27.76.1?"


    Server:
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    212.112.163.92  0.0.0.0         255.255.255.252 U     0      0        0 eth0
    172.27.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
    0.0.0.0         212.112.163.93  0.0.0.0         UG    0      0        0 eth0

    Client:
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    172.27.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
    0.0.0.0         172.27.76.1  0.0.0.0         UG    0      0        0 eth0

    Unable to access as in all traffic from a 172.27.76.X client goes to /dev/null when it hits 172.27.76.1, no ping, ssh no nothing. If I kill the tunnel it works just fine.
Children
  • 0 in reply to garnser
    I would have expected to see 172.27.76.0 172.27.76.x 255.255.255.0 instead of 172.27.76.0 0.0.0.0 255.255.255.0 for both the server and the client, where .x is the private IP of the device's interface in the local network.

    What about the route prints when you kill the tunnel - are they identical?

    What happens if you set the routes manually in the server and client?

    Cheers - Bob
    PS Did you check all of your network/host definitions to be sure none is bound to a specific interface?
  • 0 in reply to BAlfson
    I would have expected to see 172.27.76.0 172.27.76.1 255.255.255.0 instead of 172.27.76.0 0.0.0.0 255.255.255.0 for both the server and the client.

    Why? It's a layer 2 connection, not layer 3.

    What about the route prints when you kill the tunnel - are they identical?

    Yeah, IPsec doesn't take presence in any routing-table, it's just working behind the scenes.

    What happens if you set the routes manually in the server and client?

    Again layer 2

    Cheers - Bob
    PS Did you check all of your network/host definitions to be sure none is bound to a specific interface?

    Yep