Want to carve out public IPs to route to branch office

Here is my scenario:

There is a /22 block of public IPs that currently gets routed via BGP over multiple carriers into a data center. There is also a branch office that currently connects back to the data center via two private lines. There are both private and public IP blocks traversing those links.

The desire is to get rid of the private lines and use an existing dia line at the branch office and purchase one new dia connection. I(we) know how to set up bovpn for the private IPs.

We do not necessarily want to renumber out of the public IPs currently in use at the branch office. We do not want to use NAT for this part of the design.

Can we route both private IP blocks and carve out, say a /24, from the /22 and route it over to the branch office?

Comments

  • Please clarify your goal here:

    "a /24, from the /22 and route it over to the branch office?"

    Assign a /24 to internal devices at the data center?
    Assign a /24 to internal devices at the branch office?
    Something else?

  • Assign a /24 to internal devices at the branch office

    The /24, and it doesn't have to be a /24 (more than likely just a few /29s,) but a subset of the /22 would be used for public IPs at the branch office... assigned to servers and other network devices at the branch office.

  • The only way that I can see for that to work would be for all Internet traffic from the branch for that subnet to go via the data center.
    The issue is routing for the reply packets.

    I'm not up on BGP, so perhaps there is a way via BGP to point a subnet to the branch office.

  • edited January 2023

    Alright, so trying to think this through a bit. I assume the issue is asymmetric routing. Say someone on the Internet wants to get to 50.50.50.50 which is assigned to a server at my branch office. The route comes in via BGP to my data center, I have routes for 50.50.50.50 in my core routers pointed at my WG. I put some bovpn gateways and tunnels in and route that traffic over to my branch office. Routing there sends it to the server.

    Now the server replies, but it thinks/knows it needs to respond to an address out on the Internet (it doesn't know to head back out the route it came in on) and the traffic exits out the watchguard at the branch office on the regular old Internet to head back the whoever asked to talk to it. I'm assuming this is where it breaks down.

    Would there be a way to set up the routing and the WGs at each location so traffic coming in to the data center for 50.50.50.50 hits it's own designated interface on the WG with it's own bovpn tunnel and then exits out its own bovpn tunnel to the branch office. Maybe this step isn't even necessary, but possibly more importantly...

    When traffic at the branch office tries to return. Can anything be set up to make all that traffic traverse back to the data center by using any combination of separate interfaces, bovpns, gateways, tunnels, static routes into the tunnel, or as soon as it hits the external interface to my DIA line it all falls apart? I personally haven't worked with a WG in a long time. My company does a ton of WG stuff, but this falls way outside what they normally implement. Shouldn't there be a way to send traffic hitting a separate interface on the WG into a bovpn tunnel to the data center where all the tunnel overhead will be removed and those packets will get routed back out the way they came in?

    I appreciate your time.

  • One can set up a default (zero) route BOVPN at the branch which would route all traffic from a subnet to the other end of the BOVPN.

    Define a Route for All Internet-Bound Traffic
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/vpn_default_route_c.html

  • The other option is to use SNAT on incoming policies for traffic headed to that branch subnet.

    For a normal (non-zero route) BOVPN you need an entry on the incoming policies with a "Set source IP" entry to make the reply packet from the branch device go back over the BOVPN, not out the branch Internet connection.

    On the SNAT used for incoming policies for the branch subnet select "Set source IP" enter a value - discussed below

    If the BOVPN Tunnel Local setting is the trusted subnet, set the "Set source
    IP" value to the IP addr of the trusted interface.
    (Actually it can be any IP addr from the trusted subnet, but using the
    trusted interface IP addr seems more logical to me)

    Now when the packet goes down the BOVPN, the source IP addr of the packet
    will be something from the main office (the trusted interface IP addr), and
    thus the reply packet will be routed back over the BOVPN to the main office
    firewall, where it will then be Dynamic NATed and routed back to the session
    initiator.

  • Thanks. That gives me enough to work with and bring back to the people that know the WGs much better than I do. I appreciate the help.

  • The 2nd method works for Internet access to servers - the reply packet from the server going back the correct route.

    For outgoing sessions from that subnet using the 2nd method, you would need to Dynamic NAT that subnet so that outgoing sessions would go out the branch firewall and get NATed to the firewall public IP addr, and thus reply packets would come back to the branch firewall.

Sign In to comment.