Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 3870 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

Two WAN interfaces in the same subnet

INVERTO IT

 Hi,

we need a solution for the following issue:

  1. We started with one WAN interface on our UTM 9. All incoming VPNs (site-to-site and client) are configured to it.
  2. China seems to now block this IP. We can’t bring up the site-to-site VPN or client VPNs to this IP.
  3. As a workaround we configured an additional interface as 2nd WAN interface with a different IP from our WAN IP range. (unfortunately additional IPs on the WAN interface can’t be used as VPN endpoint). The site-to-site VPN from China comes up on this interface/IP.
  4. Now the problems start. The ISP router sometimes gets the wrong MAC for some of our IPs.

 

So .. two WAN interfaces in the same network subnet/segment aren’t supported.

Changing the IP on the primary WAN link is barely possible because of all the client VPNs we have out.

Can someone advice on a different approach?



This thread was automatically locked due to age.
  • 0

    If you have only a single ISP, put a small Layer 2 switch in between the ISP and the UTM.  Configure the new IP as the primary one on another interface and connect both interfaces to the switch.  Did that work for you?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0

    Based on other posts in this forum, this will be a recurring problem, because the Great Firewall does not like VPN.   I think you need a bigger strategy, and the options seem to be:

    • Find out how to convince the Great Firewall that you are securing business activity, not pro-democracy activity, so that your VPN is officially allowed.
    • Decide that there are 6 billion other potential customers or suppliers in the world, and you are going to leave the China market in protest of the Great Firewall and everything it represents.
    • Operate without VPN to comply with the constraints that the government imposes.   This might mean a lot of courier movement, but I don't know what limits they impose on digital media moving in and out of the country via courier.  This may be even riskier.
    • Operate surreptitiously, with all the risks that go with that approach. 

    Beating the system seems like the least attractive option, but if that is the plan, I would suggest these approaches.  The goal is to create a connection that looks like a web session.

    1. Shut down the connection frequently so that it looks like a client web session rather than a pipe.
    2. Try using SSL VPN over UDP 443 to look like Chrome QUIC.   If that fails, figure out if you can make SSL VPN work on TCP 443.  (This is not generally recommended because of conflicts with user portal.)
    3. Change the direction of the connection, sometimes using China as the server, and sometimes using China as the client, of the SSL/TCP session.
    4. Test whether Blast or PCOIP (VMWare), ICA (Citrix), or RDP (Microsoft) sessions can be used to give China staff access to desktop sessions on non-China servers, then upload and download files through the desktop session.
  • 0 in reply to BAlfson

    That's what we did. This started the mess. Both interfaces are responding to ARP requests with their own MAC. So sometimes, depending on who responds faster, the ARP table of the ISP router contains the wrong MAC.

    We now solved it by setting up a 2nd router and route the new IP. Would have liked to not set up an additional router.

    So a solution to the issue that the wrong interface responds to ARP requests for IPs not bound to it would be great. 

Unfiltered HTML