https://netmaker.org logo
Join Discord
Powered by
👋 reading the VPN/NAT Gateway part of your docume...
# client
g
👋 reading the VPN/NAT Gateway part of your documentation I'm having trouble understanding what's causing trouble on my (otherwise fully functional) netmaker setup. According to this part: https://netmaker.readthedocs.io/en/latest/egress-gateway.html#vpn-nat-gateway:~:text=the%20egress%20gateway.-,2)%20VPN%20/%20NAT%20Gateway,%C2%B6,-Most%20people%20think adding the network subset to the Egress Gateway is supposed to make a client properly exit trough the Egress node on the Internet. IDK if it's because I'm using 
wg-quick up a_netmaker_generated_ext_client.conf
on my tests, but as soon as I pop the VPN client up → I loose any internet connection.
I made sure that there was no overlapping between my address spaces
netmaker-1 is the Egress gateway, there is no other client on this network
hm I also tried w/ a "normal" netclient, I added a single route to 8.8.8.8/32 to ensore link availability via ICMP
no result
b
what did you set the egress gateway range to be?
g
first, I tried and followed the docs
Copy code
0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/3,160.0.0.0/5,168.0.0.0/6,172.0.0.0/12,172.32.0.0/11,172.64.0.0/10,172.128.0.0/9,173.0.0.0/8,174.0.0.0/7,176.0.0.0/4,192.0.0.0
/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4
then, seeing that it was triggering an odd behaviour I reducing the range to 8.8.8.8/32; to reproduce my issue w/ a smaller radius
hm I'm seeing an odd behaviour
@bored-island-21407 while this is true with a wireguard client (as in an ext. client generated w/ netmaker)
it doesn't apply if I use netclient and discard the "ingress" tick on the node that is supposed to mask my external IP
so, ingress + egress w/ those routes + wireguard client: no bueno egress + netclient: 👌
I think I found what was missing @bored-island-21407, I'd like to run it by you: to fix this wg-quick issue, I had to explicitely add my server public ipaddress' route (
ip r add foo.bar.baz.bam via my.lan.gateway.to.the.net dev wlan0
, i.e.) which was not done by the generated wireguard config
maybe it should be a 
PreUp
command on the generated config w/ the endpoint address & the device's default gateway?
b
interesting...
g
I haven't compared yet what differs from this while I'm successfuly netclient to run the exact same thing (using this same server as a gateway to the internet)
b
this is to get to a specific machine where the netmaker client is acting as an egress gateway for just that machine?
g
the use case that I'm trying to POC here is a workstation has to mask its public ip address on a single exit node, using a wg config (i.e. not using netclient per-se)
b
i still not sure that I completely understand what you were trying to do (and whether you were doing it with netmaker or pure wireguard)
g
ok, sorry about that, let me rephrase: I have a netmaker instance with two networks for two different purposes. The first network runs fine, it's a mesh network where all my servers are on the same wg network managed by netmaker. So far, nothing fancy. The second one, the one I'm trying to debug here, is "just a single node", my netmaker server, with a fleet of devices connected to it (ext clients) and using as a default gateway to reach the internet. To mask their identity, for instance. When I'm applying what is suggested in the docs (namely the list of ip ranges to set in the "egress"), and connecting my external client to this server, I lose Internet connectivity for a good reason: my server is on the Internet. Unless I explicitely tell wireguard to use an exceptional route (namely 
ip r add foo.bar.baz.bam via my.lan.gateway.to.the.net dev wlan0
or 
ip r add wg-server.public.ip.addr $(ip r get 1.1.1.1|awk -F 'src' '{ print $1 }'|awk -F '1.1.1.1' '{ print $2 }')
I can't reach the wg endpoint and therefore can't use it as a gateway
b
ok .... let me process that for a bit
g
i can make a drawing if it helps
b
so you are using the netmaker server as both an ingress gateway (for the ext clients) and as an egress gateway (to the internet) .... have I got that right
g
yeah indeed
it's both in and egress
b
and the ip route command is running on server? (foo.bar.baz.bam is server?)
g
the ip route command is to be run on the client
b
or you have to run that on the ext clients
g
and foo.bar.baz.bam is indeed the server, or replaced as wg-server.public.ip.addr on the second example
on ext clients yep
b
ok, gottcha ... understand it now
g
because you override the route used to reach the remote server in the first place with the AllowedIPs
b
true ... that why you can't just use 0.0.0.0/0 in allowedips
g
it's kind of the same reason yep
although you can bypass that, using an "override" ip route command explicit for this unique remoteip
as far as I understand wg mechanism, it should then be a preup command to make sure that there is an exception to all the other rules that the client will have to ingest
b
I think you are correct
g
at least my poc tells me that, I may be missing smt
b
when are you currently running that ip route command ---- before or after bring up the wg interface
g
it works either way since wg is stateless, if I haven't the route in my routing table: I lose my connection, if I have it, i can go online
b
so then it should be ok to put either in a postup or preup
g
yep
wg runtime parsing should not be trivial though since you have to retrieve both gateway and interface name with iproute commands
b
But this needs to be run on the ext client. How can the server determine the interface name of the ext client
g
the client has to run the pre-up script, but the server has to generate a pre-up script with its endpoint IP
in this case, it could be done on the ext client config template
ip r add $templated_and_known_public_ip_address $(ip r get 1.1.1.1|awk -F 'src' '{ print $1 }'|awk -F '1.1.1.1' '{ print $2 }')
idk how preup works but if it is close to bash this should do the trick
b
I see. Might work
have you tried adding that as a preup in a wg conf file?
g
it is not interpreted as is by wg, this is why i wanted to run it by you x)
Copy code
Line unrecognized: `PreUp=ipraddtemplated_and_known_public_ip_address$(iprget1.1.1.1|awk-F'src''{print$1}'|awk-F'1.1.1.1''{print$2}')'
this is what is returned by the parser
b
try adding bash -c to front of command eg.. bash -c ip r add x.x.x.x via ....
g
good idea!
it works, also: I had it in the wrong section (the good one is 
[[interface]]
)
hm good to know: android wireguard client doesnt need this preup
b
well android client does funky stuff with allowed ips
g
it is not able to read the line either btw, qr scan throws an error x)
b
fyi you can get default dev with just `ip r get 1.1.1.1 | awk '{print $5}'
g
noted
should I open an issue for this @bored-island-21407 ?
b
yes, please
g
j
Issue configuring VPN NAT Gateway
7 Views
PreviousNext
Powered by