VPN bonding DHCP problems

Home Page Forums Network Management ZeroShell VPN bonding DHCP problems

This topic contains 4 replies, has 0 voices, and was last updated by  jvandenbroek 10 years, 7 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #41432

    jvandenbroek
    Member

    Hi,

    First of all, thanks a lot for making Zeroshell, I’ve replaced my M0n0wall on a Soekris box with it! Now I’ve setup a VPN bond by using two WAN uplinks (the other end has just one WAN uplink) set to fail-over only mode, I don’t need (and want) the load-balancing to happen. The first time it is perfectly able to retrieve an IP from the remote end’s DHCP server, but after a while I get these messages in the log:

    18:55:04 	DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 13
    18:55:17 DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 14
    18:55:31 DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 9
    18:55:34 DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 5
    18:55:40 DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 8
    18:55:40 DHCPDISCOVER on BOND00 to 255.255.255.255 port 67 interval 13
    18:55:48 No DHCPOFFERS received.
    18:55:48 No working leases in persistent database - sleeping.

    Above lines are almost constantly being repeated. After the assigned IP has been expired (which is set to one day I believe) the bonding loses it’s IP. Switching DHCP manually to disabled and back to enabled will work fine, the adapter gets it’s previously assigned IP back. So it seems there are no problems reaching the DHCP server for the first time, why is that?

    I need to tell that Net Balancer is also enabled and I’ve created some balancing rules to get both tunnels through the correct WAN interface / gateway IP. Not sure if it has anything to do with that, both tunnels are being up and also worked before in a fail-over and load balancing bonding setting. I just didn’t want the load balancing to happen anymore, that’s why I switched over to fail-over only mode for bonding.

    Thanks!

    #47522

    imported_fulvio
    Participant

    It is not clear to me what interface you configured to obtain automatically the IP address. Could you post a network diagram about your VPN setup?

    Regards
    Fulvio

    #47523

    jvandenbroek
    Member

    Certainly, I’ll give it a try:

    Site A


    BOND00 (VPN01 + VPN02) DHCP enabled, fail-over only mode
    VPN01 using WAN1 interface, VPN02 using WAN2 gateway (also dedicated iface), both in Client mode
    Net Balancer configured as “Balancing and fail-over”, both uplink weights the same and set last rule to get all traffic over WAN1, with some exceptions specified above it

    SIte B


    BOND00 (VPN00 + VPN01), fail-over only mode
    Both VPN’s over the same WAN uplink in Server mode
    BRIDGE00 (ETH00 + BOND00)
    DHCP server is in the network of ETH00.

    When I first enable DHCP on BOND00 at site A, it gets an IP as expected. However, from that moment it is not able to renew it’s IP, untill I disable and re-enable DHCP manually on this interface. There is also another VPN tunnel which doesn’t use bonding or whatsoever and has another endpoint (lets say Site C). This one has no problems renewing it’s IP address.

    Also tested an uplink failure yesterday, to see if the bonded VPN would continue uninterrupted. Unfortunately it went down and didn’t come back at all, while the other internet traffic did fail-over after a minute or so.

    [edit]
    I just looked at the DHCP log and saw a successful REQ+ACK for this interface, so that seems to work now. However, the log still constantly flooded with DISCOVER messages, why is that?
    [/edit]

    #47524

    imported_fulvio
    Participant

    It is very strange. Could you try to encapsulate the BOND00 interface in a BRIDGE00 one and enable the dhcp client on this?

    I tested (beta11) the VPN bonding only in failover and load balancing and it worked fine. The modality “only failover” could not work correctly. In this case I will fix it for the next release. In any case, VPN bonding is necessary only to increase the layer 2 traffic among remote offices by using the load balancing. If you just need of a VPN with fault tolerance the bonding is not necessary. You just need to configure the Net Balancer with the multi-gateways and then select the preferred link in the site-to-site VPN configuration.

    Regards
    Fulvio

    #47525

    jvandenbroek
    Member

    I’ve encapsulated BOND00 in BRIDGE00 and activated DHCP on it, now the problem with the discover messages seems to be gone! That’s great, thanks.

    My idea of bonding with fail-over only for VPN was that the VPN would stay alive in a event of link failure, or just with only a few secs of downtime. Isn’t it true that the Net Balancer fail-over would take longer to happen than having two active tunnels of which one gets down and bonding is doing the fail-over part instead? If not, than I can see it’s much easier to just setup one tunnel and let Net Balancer do the fail-over.

    I’ll have to test fail-over again with the bonded VPN being bridged, maybe that now also works as expected. I’ll let you know if that is the case.

    Thanks a lot.

    – Joost

    [edit]
    I’ve tested fail-over today by pulling WAN1’s plug, but BOND00 still doesn’t fail-over. It sees that VPN01 is down, but simply won’t change the active slave. Other traffic does, as said before, fail-over as expected.
    [/edit]

    #47526

    jvandenbroek
    Member

    Another issue I ran into today: The Soekris box was completely frozen this morning, had no to time connect a serial cable and needed the internet back asap. After resetting the box it fortunately all was working again. However, that’s why I post this in this thread, the bonded VPN was also brought back up, but the bridged interface was down (it’s checkbox ‘Up’ was marked). After manually bringing the interface down and back up, it also worked fine. I think the bridge tried to get up before the bonded interface, so it couldn’t assign it to the bridge. Well, that’s what I assume, maybe it’s not the cause at all.

    Regards, Joost

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.