OPNsense Forum
English Forums => Virtual private networks => Topic started by: RamSense on September 18, 2021, 11:49:42 am
-
who has experience in using Wireguard at public wifi spots like mc Donalds / schools etc?
I want my kids to being able to secure their iPhone wifi connection at public wifi networks without that public wifi point blocking Wireguard as it is now at mc Donalds and their school.
What is the best port or method to use to prevent their vpn being blocked?
-
I use port 443 udp and not had an issue but you can also try port 53 udp.
-
thank you allebone for your suggestions. I have only in my opnsense port 53 forwarded to adguard home (plugin) and port 443 to nginx proxy for local website. So I think I can not use those ports with adguard and nginx (?).
Do you have any other suggestions? Or do you think your mentioned ports work with my opnsense settings mentioned above?
-
You have port 53 open to the whole internet?? I would recommend you dont do that. Perhaps you can explain your setup.
-
No only internally see the attached picture.
Setup is simple. ISP - opnsense (with adguard home plugin) - wifi router -> wired connected nas/website
-
Ok thats fine. If you dont forward on your wan (pic shows lan interface) port 53 then you can do a nat rule on port 53 and redirect to a different internal port that wireguard runs on. So rule is interface wan, ipv4, udp, destination - 53, redirect to target port 51820 (or whatever you set wg port to be).
That way witeguard tuns on a different port internally but externally, someone contacting your wan address on port 53 udp is redirected internally to the wg port.
That should bypass most airports etc with restrictions.
P
-
ah that sounds great indeed!
But you stated also You have port 53 open to the whole internet?? I would recommend you dont do that. Perhaps you can explain your setup.
Is this method safe than?
And do I make this rule in Firewall: NAT: Port Forward: interface wan, ipv4, udp, destination - 53, redirect to target port 51820 (or whatever you set wg port to be).
or
Firewall: Rules: WAN: interface wan, ipv4, udp, destination - 53, redirect to target port 51820 (or whatever you set wg port to be).
I think the last one? Firewall: rule: wan?
-
Yes it is safe because you are not exposing dns to the internet. Wireguard is designed to be exposed to the internet. The port is not relevant. My question was, did you expose adguard to the internet on port 53 (that is unsafe).
You should create a nat rule. firewall - NAT. The appropriate rule will be created automatically when you make the NAT rule. You can see it and check its correct in firewall, wan, rules afterwards. Making the NAT rule will make the second rule for you.
P
-
ah yeah, now I follow you.
I have port 53 not exposed to the internet. so only LAN like you stated.
I will try your setting and indeed port 53 and than forward on opnsense to the WireGuard port and test it on public wifi.
sounds like a great solution indeed.
thanks!
-
Let me know how it goes and I can help further if need be.
-
this did not work.
vpn connects, but no browsing/data
in the client config I put also port 53
put when I put my destination port in, it also connects and works. strange(?)
What have I done wrong?
-
I tested on my firewall and it works perfectly so you will have to check your rules etc. You should do basic troubleshooting steps like checking the opnsense server sees a handshake, if you can ping (rule out a dns issue etc) and wotnot and report back with any interesting findings. Mine was running in port 443 and I just opened port 53 to redirect to 443 in addition and it worked without changing anything further so must be something your side that could be stopping it.
-
Ok, so my port forward rule screen capture was correct (?)
I will check what I can find.
Thanks
-
Assuming your FW is 192.168.1.1 and WG runs on port 989 UDP then it looks correct to me.
-
Can it be that my ISP is blocking incoming port 53 wan?
Is there a way to check this? I tried also to use a port below 1000 to see if that is any useful on public wifi, did not test it yet though.
-
I feel this would be a lot easier to test if you didnt leave your home and just checked it was working from your phone when you turn wifi on and off. Maybe start there as being able to switch back and forth is a lot easier.
-
I did a test with shieldsup - https://www.grc.com/shieldsup (https://www.grc.com/shieldsup)
And I can see port 53 is not open. I can open other ports like 443. So it definitely looks like the ISP is blocking port 53 before it even hits my router....
-
That would make it much harder. To test you would need to change the port to something else in your rule without changing anything else and confirm it works and then if this is the case consider another port to use that might bypass. The best is 53 and 443 but if those are out the question you might have success with port 465 as many firewalls allow this port (secure mail for gmail for example).
-
Not OP, but same problem here. Not a matter of port blocked by ISP. I tried on port 80 which i know isn't blocked but no go. Also tried port 51821 for testing but no luck.
Firewall-> NAT-> Port Forward:
Interface: WAN
TCP/IP: IPV4
Protocol: UDP
Source: any
Destination: WAN address
Destination Port Range: 51821-51821
Redirect Target IP: Single Host or Network: 192.168.1.1 (also tried 127.0.0.1 and Wireguards 10.0.0.1)
Redirect Target Port: 51820
I thought this should be good but it isn't. What am i missing here?
-
Did you make sure under wireguard - local the port you are redirecting to is what wireguard is running on. Mine works totally fine. Here is a rule example of mine that works:
(My wireguard runs on 443 but I opened port 53 externally as a test.)
-
My Opnsense IP is 192.168.2.2 in case you wondered.
-
Did you make sure under wireguard - local the port you are redirecting to is what wireguard is running on.
Yes, Wireguard is running on 51820. Clients connecting to that port directly get a handshake just fine.
So, if your config works, then OP's and mine should work as well yet they don't. There must be something else then; some setting or rule both OP and I have in place which prevents us from port forwarding to services running on the firewall itself. @OP can you confirm NAT port forwarding is working for a different machine in your network? I know this works on my end:
Firewall-> NAT-> Port Forward:
Interface: WAN
TCP/IP: IPV4
Protocol: TCP/UDP
Source: any
Destination: WAN address
Destination Port Range: 51821-51821
Redirect Target IP: Single Host or Network: 192.168.10.10
Redirect Target Port: 8888
When i use a browser and connect to http://my_wan_ip:51821 i now get the web interface for Chronograf running on my Pi3@192.168.10.10:8888.
So NAT port forwarding is working, just not for services on the firewall itself so it seems.
edit: for anyone wondering (i did ;) ), NAT port forwarding does also work for devices in the same VLAN as the firewall, i tried above config but redirecting to 192.168.1.10:80 -which is a switch- and i get the switch's web interface.
-
Ok I am running wireguard in kernel mode. Not the wireguard go version. What do you have?
-
Wireguard go. But i don't think that's the issue; I just tried port forwarding for OpenVPN and that doesn't work either.
-
That would make it much harder. To test you would need to change the port to something else in your rule without changing anything else and confirm it works and then if this is the case consider another port to use that might bypass. The best is 53 and 443 but if those are out the question you might have success with port 465 as many firewalls allow this port (secure mail for gmail for example).
You're correct. I tried port 465 and did not change anything. Only at the client config I changed listen port 465 and endpoint ip:465
tested it, but I could not load any website...
so I did something wrong with the port forward or the client config? see attachment
-
Why not just have WG listen on 465 and forget about port forwarding?
-
Why not just have WG listen on 465 and forget about port forwarding?
Greelan, my default working WG is configured with this firewall-rules-wan ->see attached picture.
When I remove this rule, my WG stops working?! Do I understand you correctly that my WG should be working without this rule?
-
No, you need a fw rule. But why not a rule to port 465, with WG listening on that port instead of 989?
-
Ah ok, well it was for testing if another port is working, while not modifying the WG config. The port 53 seems to being blocked by my ISP
-
I cant understand why you guys cant get redirecting from a different port to work. On mine it works perfectly fine. I can run wireguard on any port And just redirect a different external port of my choosing. Honestly I dont see how this cant work for you. Its like a basic feature of the firewall to be able to do this.
Maybe you guys are removing the rule that allows wireguard to listen in the port its configured. Can you rule this out by having 2 nat rules (one original rule to the same wireguard port its listening in and a second nat rule where the redirect is performed). If this scenario works then you guys are deleting the rule to allow wireguard to service requests on the port it is listening on which would break it obviously.
-
I don’t have this issue (I don’t forward ports to services on my firewall). I’m just trying to help the OP with an alternative.
Perhaps show the OP an example of a working rule of yours, so he can compare. Eg what target IP are you using?
-
Yup J posted this already. It goes to the opnsense ip address.
-
I have it working now for port 465. I made a terrible mistake in my earlier port forward using tcp instead of udp... :-[
Now I can use WG on 465 also. port 53 does not work being blocked by my ISP.
Will try 465 at public wifi to see if it will work....
-
See - I told you it had to work.
GG.
Pete
-
I know i can just run Wireguard on a different port but Port Forwarding should work, right? Why doesn't it? I must be doing something wrong and I like to know what. Please see attached images for my NAT and WAN rules.
What am i missing here?
-
MTR you cannot redirect to ‘wan address’ as this is the external ip of the firewall. Try redirecting it to 192.168.1.1 in your case.
-
Under NAT -> Port Forward i have destination WAN address with port 15821 and NAT 192.168.1.1 with port 15820.
Under WAN the first rule is for normal Wireguard, and the second one is linked by the NAT rule.
Is this not right?
-
Under my rules, wan the destination is the internal IP of the firewall not wan address (mine is working so assume correct?). Probably because of stateful inspection the bottom wan rule is never hit (the rule above stops further processing of rules). You could try reorder the bottom rule and move it before the rule that is to wan address in your screenshot.
Im pretty sure this is the issue because I only use nat rules even when forwarding to the router itself (ie as opposed to just opening the wan up directly). The reason for this is in my case I use IDS/IPS on the LAN interface so without making the packet process through the lan the router itself will not have this port protected by any filtering you have in place. Indeed some small cost of a cpu cycle is incurred by the packet having to move across and interface but a faster CPU can mitigate that and probably the cost is so small you will be unable to detect it. The same reason could apply if you used sensei on the LAN.
Also I am pretty sure a nat rule is the default way it was done in the documentation before, but I did just check and it is no longer like that so I think this was changed in the documentation at some point because I assumed everyone did it this way, and at one point Im fairly confident it was the case.
-
I followed the road warrior setup guide (https://docs.opnsense.org/manual/how-tos/wireguard-client.html), hence the rule with Destination WAN address under Rules->WAN.
Under my rules, wan the destination is the internal IP of the firewall not wan address
Yes, the NAT rule creates a rule under Rules->WAN which says destination <internal_ip>. Destination in the NAT rule is WAN address tho (yours says PPPoEWAN address, according to the screenshot you posted earlier.
Probably because of stateful inspection the bottom wan rule is never hit (the rule above stops further processing of rules). You could try reorder the bottom rule and move it before the rule that is to wan address in your screenshot.
Tried that, no-go.
Im pretty sure this is the issue because I only use nat rules even when forwarding to the router itself (ie as opposed to just opening the wan up directly).
For testing i removed the rule i made in WAN, going only with a NAT rule as you suggested. This works (client connecting to 51820):
(https://i.ibb.co/d0154GV/NAT.png) (https://ibb.co/fYBxd4y)
But this does not (client connecting to 51821):
(https://i.ibb.co/fCMVQ3F/NAT2.png) (https://ibb.co/D74PLBW)
Do you have only 1 NAT rule for Wireguard and nothing more (except from the linked rule under Rules->WAN)?
-
Currently because I was testing for you guys I have 2 rules:
NAT
Rules
However they both work currently. Presumably as mine work and you are wanting to achieve the identical setup (one forwards to same port, the other redirects from a different port) yours should also work (when you have 2).
Dont forget to modify the port on the client connecting afterwards. Thats also a requirement obv.
P
-
Here is the proof it works from an iphone. My iphine gets an ipv6 address so thats why the endpoint looks strange but I assure you this works on ipv4 clients also (just easier to rest from my phone quickly).
(https://i.imgur.com/Cv9JtgQ.jpg)
(https://i.imgur.com/KloehJ5.jpg)
-
Here is the proof it works from an iphone.
No worries, i'm totally convinced your setup works. I appreciate the time you take to try to help me! :)
So far i tried:
a) One WAN Rule (dest. WAN Addess, port 51820) and one NAT (dest. WAN Address, port 51821 redirect to 192.168.1.1 port 51820)
b) Two NAT (one dest. WAN Address port 51820, redirect to 192.168.1.1 port 51820 and one dest. WAN Address port 51821 redirect to 192.168.1.1 port 51820)
c) One NAT rule only, redirect dest. WAN Address port 51821 to 192.168.1.1 port 51820.
With options a) and b) i can successfully connect to endpoint my.wan.ip:51820 but as soon as i try my.wan.ip:51821 i can't get a handshake.
Option c) also fails handshake when connecting to my.wan.ip:51821
Same problem when i try to redirect a port for OpenVPN; no connection possible.
When i redirect a port to a different machine in my network everything works as it should. Just not when i redirect to a service on the firewall itself. ???
I even tried less-sensical options like opening 51821 and 51820 from all sources in Rules -> LAN, Loopback and WAN, setting ListenPort in clients [Interface] config and what not. All without success.
I don't know what else i can try to make this work and frankly i'm getting fed up with this. At first i wanted to solve this just because it should work but now i'm ready to throw the towel and just run Wireguard on a different port. Gonna watch me some brilliant CL soccer now, PSG-ManC. Hopefully that match will be good. This one wasn't: FW-MTR 1-0. ::)
edit: added option c) to things i tried.
-
I cant explain why it doesnt work for you. I mean I am totally stuck on what to look at next. I cant think of a reason what could be causing you an issue :(
-
Me neither. This should work but it doesn't. Thanks again for your help though!
* PSG-ManC is 1-0 at half time. Maybe i should consider my match half time as well. As in i might take another look. Some day. If anybody reading this has anything to add, please do.