Default Gateway on Different Subnet

Discussion in 'ISPConfig 3 Priority Support' started by BobGeorge, Nov 28, 2017.

  1. BobGeorge

    BobGeorge Member HowtoForge Supporter

    My LAN is on 10.0.0.0/8 and I've been given a small block of IP addresses and a gateway address by my ISP (WAN addresses).

    The problem is that the gateway address given to me is not in the 10.0.0.0/8 subnet.

    So I want, for example, 10.0.1.1 to use the default gateway of, say, 1.2.3.4 (a WAN address) but because they're not on the same subnet, it's not working. But they are attached to the same switch, so they can physically contact each other - I can ping the WAN address from the LAN, no problem.

    Is there a way to specify - on Ubuntu - that the LAN is 10.0.0.0/8 + the default gateway WAN address? Or set the default route manually so that it'll send to the WAN?
     
  2. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    Couldn't you set the default gatway? E. g.
    Code:
    route add default gw 1.2.3.4 eth1
    if eth1 is the network card for the private network (and not for the public ips of course).
     
  3. BobGeorge

    BobGeorge Member HowtoForge Supporter

    Actually, upon further investigation, it rather oddly turns out that it was working all along. Sort of.

    Packets sent to the gateway are actually going out, but I forgot about how the load balancing works in my set up.

    Incoming packets go to the load balancer, which chooses a real server and then hands it the packet. The real server then responds directly to the client. But when the client responds, tt doesn't go back to the real server directly, rather it goes to the load balancer. The real server's outgoing packet has the VIP address - a shared address between the whole cluster, which always goes to the load balancer for it to distribute the packets to the right places.

    So, for example, when I do "ping google.com", the pings are going out via the gateway, but the responses are coming back to the load balancer. But as the load balancer did not send out those pings - the real server did - then they are not "ESTABLISHED, RELATED" as far as the load balancer is concerned, so it DROPs the packets at the firewall.

    Thus, the gateway is working, but I'm not getting responses back, as they are coming back via the load balancer (which, as the interface with the outside world, has a firewall that's set to be very conservative and reject everything by default, just opening things up only where needed to let a service through).

    I could solve this by handing out the WAN IP addresses to each node - then they can communicate through the gateway and receive replies directly back (and I tried this and it worked) - but I don't have enough WAN addresses (it's only a small block of half a dozen that the ISP has given us) for all the nodes, and certainly won't have enough going forward, when we install a few more storage servers and such.

    So, basically, I need to do some NAT. This wasn't a problem with our old network, as that router had NAT built-in. But this connection that the ISP has given us is a bit more "raw". It exposes half a dozen WAN addresses, plus a gateway and a broadcast. And that's it, and I'm not allowed or able to to change that ISP router's configuration.

    Therefore, I'm going to have to implement NAT manually. Either through my switch or, you know, playing with "iptables" to make a NAT box as a local gateway for the LAN that can NAT it out through the real ISP gateway.
     
  4. BobGeorge

    BobGeorge Member HowtoForge Supporter

    I was previously using LVS-DR (Direct Routing), so that packets would come in to the load balancer and then simply have their MAC address changed and were passed on otherwise untouched to the real server, who would reply directly to the client.

    But if one takes a step back and remembers that, actually, the old router we had was providing NAT for the local LAN, then what was really happening was that the packets were coming in to our external IP address, were being NAT'd to its LAN equivalent, then were having their MAC address changed and were passed on to the real server, who would reply as the LAN VIP to the gateway, who'd un-NAT it back to our external IP address.

    Or, in other words, there was actually two layers of translation going on. The NAT in hardware and the LVS-DR in software.

    Remembering / realising that this was the case and faced with the fact that the new router simply provides us with our block of IP addresses and doesn't do any NAT / LAN stuff for me - that this aspect of things I needed to implement myself manually - it dawned on me that I should fold both things together and I switched to using LVS-NAT instead.

    In this variant of LVS, rather than changing the MAC address on the incoming packets, it uses NAT and changes the destination IP address.

    So "client -> external address" is NAT'd to "client -> LAN address", processed and the return packet is un-NAT'd from "LAN address -> client" to "external address -> client" on the way out.

    This does mean that the outgoing packets have to be passed back via the load balancer to ensure the NAT is undone - which is an extra step, so generally LVS-DR would be preferred for performance - but, in fact, I need to NAT my LAN anyway, as the new router doesn't provide that as the old one did, and so it's not really an extra step, but is rather folding two incoming steps (NAT and load balancing) together and is just doing the outgoing step (un-NAT) explicitly.

    That's hardware abstraction for you. Sometimes it does such a good job, you forget it's there.

    But, in this case, I needed to remember it was there to come to the realisation that the actual solution was to change the load balancing method entirely.

    This not only works but is slightly better. Collapsing two steps - hardware and software - into a single software step and now having a strict separation of WAN and LAN (they can't access each other at all, except via the load balancer). Sorted.
     
  5. BobGeorge

    BobGeorge Member HowtoForge Supporter

    Now comes my next consideration.

    The IP addresses have all been changed to the new network underneath ISPConfig.

    What's the best / safest method to apprise ISPConfig of these changes?

    Via the "Server IP addresses"? And would that be a case of adding the new address and then deleting the old or...? Or would it make more sense to just dive into "dbispconfig" with PhpMyAdmin and just manually change the numbers? Plus, are there any other places - files - that would need updating?

    References to host names, rather than IP addresses, should be fine, as I've already made the changes to my "hosts" file.

    (Yes, this is really a new question, but not sufficiently unrelated to deserve firing up a new thread for it, I feel.)
     
  6. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    The question is where you are using the old IPs inside of ISPConfig. If it's only on "server ip addresses" then you can safely edit the old and replace it by the new one.
    If you used in on websites inside ISPConfig, I'd prefer changing it in the dbispconfig database and then do a tools -> resync for websites.
     

Share This Page