Re: wireguard and shorewall

Let me describe my road warrior setup - fake addresses/ports for the example.

My VPN server is on a DMZ inside with a DNAT to it on the firewall but for 
the example let's assume it is on the Internet with address 1.1.1.2. So, 
server config wg0.conf:

"
[Interface]
PrivateKey = <server private key>
Address = 10.1.1.1/24
ListenPort = 44444

[Peer]
PublicKey = <peer1 public key>
AllowedIPs = 10.1.1.2/32

[Peer]
PublicKey = <peer2 public key>
AllowedIPs = 10.1.1.3/32
"

When this config is applied, the Wireguard kernel listens on port 44444 at 
the default address. Also interface wg0 has the address 10.1.1.1/24 and 
there is a route set up to 10.1.1.0/24 via 10.1.1.1.

Note that there is no 'Endpoint' config for either peer as on the road they 
could come from anywhere on any port. For known hosts connecting to each 
other then each would have the Endpoint of the other.

Now the road warrior wg0.conf for peer1:

"
[Interface]
PrivateKey = <peer1 private key>
Address = 10.1.1.2/24

[Peer]
PublicKey = <server public key>
AllowedIPs = 10.1.1.0/24, 172.16.0.0/16
Endpoint = 1.1.1.2:44444
PersistentKeepAlive = 25
"

The config for peer 2 would look similar but the [Interface] section would 
have its own private key and Address = 10.1.1.3/24.

On bringing up wg0 on the road warrior it will try to connect to the server 
on 1.1.1.2:44444 via its own default route. wg0 interface will get the 
address 10.1.1.2/24 and there will be routes set up to 10.1.1.0/24 and 
172.16.0.0/16 via wg0.

You could put AllowedIPs = 0.0.0.0/0 on the client to have all traffic go 
down the tunnel (except the Wireguard tunnel packets).

HTH John

On 05/12/2020 11:11, Erich Titl wrote:
> 
> 
> Am 05.12.2020 um 00:15 schrieb John Sager:
>>
>>
>> On 04/12/2020 21:19, Erich Titl wrote:
>>> Hi John
>>>
>>> Am 04.12.2020 um 19:17 schrieb John Sager:
>>>> Let's call the two ends A & B. Each has an 'outside tunnel' address via 
>>>> which they communicate with each other. These should be the 'Endpoint' 
>>>> for the far end in the respective conf files, together with the port 
>>>> that Wireguard listens on at the far end.
>>>
>>> What are the respective parameters for these end points
>>>
>>> I have on the central site, my internal network us on my own public (but 
>>> unrouted) class C network 194.124.158.0/24
>>>
>>> [Interface]
>>> Address = 192.168.17.1/24
>>> PrivateKey = _my_private_key_
>>> #ListenPort = 11194
>>> #
>>> #
>>> # Peer1
>>> [Peer]
>>> PublicKey = _the_other_public_key_
>>> AllowedIPs = 192.168.17.2/32
>>>
>>> Where does one define which ip the outside packet takes
>>
>> That is 'Endpoint = <B's address:port>' defined under [Peer]
> 
> Which is not defined in the example and I have not found any document on the 
> net which defines 'Endpoint'
> 
>>
>> Obviously you must already have a route defined to B as wg-quick won't set 
>> that up - it only sets up routes in AllowedIPs.
>>
> 
> Well, the endpoint B appears undefined so it might use the default route 
> (wrongly).
> 
> Here is my Peer config snippet now, I leave ListenPort to the default right 
> now.
> 
> [Peer]
> PublicKey = _peers_public_key_
> AllowedIPs = 192.168.17.2/32
> Endpoint = 194.124.158.76
> 
> But wireguard does not like this
> 
> gatekeeper# /etc/init.d/wireguard restart
> Stopping wireguard VPN server on interface wg0
> [#] ip link delete dev wg0
> Starting wireguard VPN server on interface wg0
> [#] ip link add wg0 type wireguard
> [#] wg setconf wg0 /dev/fd/63
> Unable to find port of endpoint: `194.124.158.76'
> Configuration parsing error
> [#] ip link delete dev wg0
> 
> It looks like wg_quick does not like empty ports, so
> 
> [Peer]
> PublicKey = _peers_public_key_
> AllowedIPs = 192.168.17.2/32
> Endpoint = 194.124.158.76:11194
> 
> Now this looks better
> 
> gatekeeper# /etc/init.d/wireguard restart
> Stopping wireguard VPN server on interface wg0
> [#] ip link delete dev wg0
> Starting wireguard VPN server on interface wg0
> [#] ip link add wg0 type wireguard
> [#] wg setconf wg0 /dev/fd/63
> [#] ip -4 address add 192.168.17.1/24 dev wg0
> [#] ip link set mtu 1420 up dev wg0
> 
> 
> but:
> 
> gatekeeper# ping 192.168.17.2
> PING 192.168.17.2 (192.168.17.2): 56 data bytes
> ping: sendto: Destination address required
> 
> So it appears there is no way to set up a road warrior as the central peer 
> needs the address of the remote peer
> 
> And even though I con ping the local tunnel endpoint now
> 
> gatekeeper# ping 192.168.17.1
> PING 192.168.17.1 (192.168.17.1): 56 data bytes
> 64 bytes from 192.168.17.1: seq=0 ttl=64 time=0.329 ms
> 
> It requires quite some twiddeling with shorewall until the remote tunnel 
> endpoint can be reached, which brings up the shorewall issue on both sides.
> 
> I still cannot see how to bring up a road warrior this way.
> 
> cheers
> 
> ET
> 
> 
> ------------------------------------------------------------------------
> leaf-user mailing list: [email protected]
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/
> 


------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/