Hi folks,
I'm having some strange issues with a customer's setup regarding a XG115 on firmware 17.1.3 MR3. To clarify I'll describe the setup with the following picture:
I created a bridged interface where both XG's port share the same subnet (to have a little more segmentation between clients and servers), each interface ends on a 24port switch. The bridged interface has the IP 192.168.0.1/24. The XG has two internet connections, both realised as PPPoE with attached Zyxel DSL modems.
Problem 1:
My first problem is that DHCP doesn't work anymore. I can see hits for the DHCPOFFER from the server, but no client successfully gets an IP-adress. A virtual machine that is on the same "side" of the network as the server is able to fetch an IP-adress, so it does not seem to be a server problem. As a workaround I actually disabled the DHCP server on the DC and activated it on the XG. A LAN-to-LAN firewall rule exists (source zone LAN, subnet 192.168.0.0/24, destination zone LAN, subnet 192.168.0.0/24, services: any).
I already tried activating DHCP relaying, but that did no difference. As written above, I can see the offering from the server passing from port 2 to port 1, but no replies.
Problem 2:
Much more frustrating is the following. As you can see the customer has 3 VPN site-to-site connections running over the 2 WAN ports. The connection to the "orange" side (port 4) is fine (VoIP-datacenter connection), as well as the "green" connection to the 192.168.158.0/24 subnet (Sophos SG). The connection from 192.168.52.0/24 connects over a Cisco ASA 5510, since the network has to be NATed the IPSEC SA contains 10.1.24.0/24 as the XGs LAN network. In the VPN configuration on the XG the 10.1.24.0 network is selected for the local network, NAT is activated and the "real" LAN subnet is selected to be NATed to.
The tunnel comes up with no issues and I am able to ping from customer to us (the 192.168.52.0 subnet is our internal network). This runs up to hours without any issues. At the same time I am connected via OpenVPN to the customer and am pinging internal ressources without an issue.
It turns weird if I try to ping through the tunnel from our side. I spent plenty of time troubleshooting and can say the following now:
1) I ping a client (located on the switch attached to Port 1 of the bridged interface)
- The client answers through the tunnel as well as through SSLVPN.
- I lose connection to the server side in SSLVPN.
- the customer's servers are losing their internet connection.
- internal pings over the bridged interface are working well
- I am not able to reach anything on the "server Port" through the tunnel.*
2) I ping a server (located on the switch at Port 2)
- The server answers through the tunnel as well as through SSLVPN.
- I lose connection to the client side in SSLVPN.
- the customer's clients are losing their internet connection.
- internal pings over the bridged interface are working well
- I am not able to reach anything on the "client Port" through the tunnel.*
* If I change the "destination side" after the first 4 pings sometimes I get answers from the other side (and the OpenVPN part answers, too). First ping target then changes to unreachable. But if I wait let's say 10 seconds that change doesn't work anymore. Sometimes I get a TTL exceeded.
If I forcefully bring down the VPN tunnel with the NAT translation I get answers from all targets in OpenVPN again and the Internet connection at the customer is back online.
Does anyone have any suggestions to the two problems?
Thanks!
This thread was automatically locked due to age.