Topic: Wireguard Update

[mmccarn]

My macbook started having trouble accessing the internet if I was not at home, or if I did not have OpenVPN connected to my work network.

For some reason my default DNS server from many locations is the PiHole server I have at home (yes, this is a separate, macOS issue...)

In November an on-demand Wireguard connection provided access to the pihole server on me SME network and life was good...

The only recent update to Wireguard was Wireguard Bug 12288 "MASQUERADE create unexpected result".

Reverting the changes from that bug got my Wireguard VPN (and DNS, and plex) working again.

Code: [Select]

cd /etc/e-smith/templates/etc/wireguard/wg0.conf/
mkdir -p $(pwd |sed 's/templates/templates-custom/')
sed 's/^#Post/Post/' 10interface > $(pwd |sed 's/templates/templates-custom/')/10interface
signal-event wireguard-conf-modify

Thank you JP for commenting out the old code instead of removing it!

[Jean-Philippe Pialasse]

Hi
I also uses a pihole through the wireguard tunnel and works great without the lines.

You must consider that those lines are only executed on startup of Wireguard, and they will always be overrided if one restart or reload masq....

to restore access to your pihole just add the subnet of your wireguard to your pihole (advanced editing needed) or simply configure it to "Respond only on interface eth0". As your pihole is behind your SME or another firewall this is not an issue to set it this way.

[mmccarn]

Thanks.

My pihole is already responding on eth0...

I freely admit that my problem is of my own creation:
* My SME is server-only
* and is not the default gateway on my LAN
* and I have far too many servers running at home
* and I am (perhaps over-) cautious when setting up server firewalls

With wireguard masquerading disabled:
* return routing of traffic from LAN endpoints to wireguard clients doesn't work. 
  I can fix this by adding a static route to my firewall.

* firewall settings on most of my LAN hosts block traffic from outside the current LAN
  Fixing this requires reviewing, adjusting, and testing the firewall settings on 10+ hosts...

With the original PostUp and PostDown declarations, wireguard masquerades client traffic from the SME LAN IP.  The masquerading eliminates the need for extra routing or server adjustments at the cost of some granularity over which hosts are accessible to specific wireguard clients.

Could the masq reload issue be resolved by adding PartOf=masq.service to /usr/lib/systemd/system/wg-quick@.service?

[Jean-Philippe Pialasse]

indeed the wireguard was thought for a server gateway perspective.


rules for the wireguard network should be added only on the main router of the network so they are propagated to all clients.

Could the masq reload issue be resolved by adding PartOf=masq.service to /usr/lib/systemd/system/wg-quick@.service?

partly. the start/stop will handle the situation. for the restart not sure but it should too, if wireguard is stopped. 
for the reload i do not hink it will do anything but should test. 

better approach would be to add those rules in the masq script at the right spot . check jow it is done with open vpn s2s when snat is enabled.
and it could be an option to enable it.

way it was done on top of being unstable was forcing it on other network while it was working.  failing ip based tests for services such as zabbix agent/ zabbix server

[Jean-Philippe Pialasse]

so here the two fragments that we could start from.

we should
- get the wireguard network
- use a different name for the chain and fragments
- use right interface

cat /etc/e-smith/templates/etc/rc.d/init.d/masq/40snatVPN

Code: [Select]


    # Will handle SNAT for Site to Site VPN
    /sbin/iptables --table nat --new-chain SnatVPN
    /sbin/iptables --table nat --new-chain SnatVPN_1
    /sbin/iptables --table nat --append SnatVPN -j SnatVPN_1
    /sbin/iptables --table nat --append POSTROUTING \
        --out-interface tun+ -j SnatVPN

cat /etc/e-smith/templates/etc/rc.d/init.d/masq/90adjustSnatVPN

Code: [Select]

{   
    my $ovpndb = esmith::ConfigDB->open_ro('openvpn-s2s');

    # Find the current SnatVPN_$$ chain, and create a new one.
    $OUT .=<<'EOF';
    OLD_SnatVPN=$(get_safe_id SnatVPN nat find)
    NEW_SnatVPN=$(get_safe_id SnatVPN nat new)
    /sbin/iptables --table nat --new-chain $NEW_SnatVPN
EOF

    foreach my $vpn ($ovpndb->get_all_by_prop(type=>('client')),
                     $ovpndb->get_all_by_prop(type=>('server'))){
        $OUT .= "    /sbin/iptables --table nat --append \$NEW_SnatVPN --out-interface tun" . $vpn->key .
                " -s " . $vpn->prop('LocalIP') . " -j SNAT --to-source $InternalInterface{'IPAddress'}\n"
                if (($vpn->prop('SnatOutbound') || 'yes') =~ m/(yes|enabled)/i);
    }

    # Having created a new SnatVPN chain, activate it and destroy the old.
    $OUT .=<<'EOF';
    /sbin/iptables --table nat --replace SnatVPN 1 \
            --jump $NEW_SnatVPN
    /sbin/iptables --table nat --flush $OLD_SnatVPN
    /sbin/iptables --table nat --delete-chain $OLD_SnatVPN
EOF

}



current commented out code

Code: [Select]

#PostUp = iptables -I FORWARD -i %i -j ACCEPT; iptables -I FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
#PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o br0 -j MASQUERADE


[Jean-Philippe Pialasse]

note all the forward part is provided by the network being defined in the known local network of SME.