Routing from subnet does not belong to pfsense

[johnpoz]

@josifbg-0 they are not routing through the tunnel then.. If they are hole punching, then you would have to allow the actual connection outbound in the first place to allow for the whole punch. Maybe the port has to be static for what they are trying to do with the hole punch.

But traffic flowing though that tunnel pfsense has zero to do with any of that traffic.. Not unless pfsense was the actual endpoint in the vpn could it control traffic in or out of the tunnel.

[Josifbg 0]

here are some logs:

WAN udp 94.XX.XX.XX:13355 (192.168.20.125:51821) -> 18.192.50.92:45328 SINGLE:NO_TRAFFIC 901 / 0 155 KiB / 0 B

[Josifbg 0]

@johnpoz I totally agree with you and it was strange for me as well why this is happening.
"then you would have to allow the actual connection outbound " -> well this got to my mind as well but I am not sure which connection to open and where in the pfSense

[johnpoz]

@josifbg-0 said in Routing from subnet does not belong to pfsense:

WAN udp 94.XX.XX.XX:13355 (192.168.20.125:51821) -> 18.192.50.92:45328 SINGLE:NO_TRAFFIC 901 / 0 155 KiB / 0 B

That is client 20.125 leaving psense wan - it gets no answer - how is that a pfsense thing? But notice your port on wan left at 13355 but the client source was 51821.. If in that udp packet it told this 18.192 box to come back on port 51821 - pfsense would not allow that traffic because it would be out of state an not able to hole punch.

You would need to set a static nat on such traffic - where pfsense when it nats it, if the source is 51821, when it leaves pfsense wan it would stay 51821 vs being port natted to that 13355 port.

https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#static-port

[Josifbg 0]

@johnpoz This totally makes sense.

So I have to create static port 51821 right?

[johnpoz]

@josifbg-0 If that is the port your vpn client is going to use to tell the other site/client how to hole punch back directly to him yes.. Is there a setting for that port in the client?

Its a horrible design flaw in such clients... The other end that is going to hole punch back should just use the port it got the traffic from.. In your example that 13355 port..

[Josifbg 0]

@johnpoz From the Server side ... the Netmaker Server I am able to control that for the whole network or per each node/client

So, Yes I can make changes to the client, but again I am not really sure how to set it up in pfsense....

Here are some rulz I`ve created but still not working

the Outbound rule:

the port forward rule:

Here are the changes to the client/Node in the Netmaker server:

[Josifbg 0]

@johnpoz I did it! I guess I did it

Here are the final changes which has to be made in pfSense:

The Outbound Rule:

And some changes to the node which is behind pfSense in Netmaker Server:

That`s it!

Thank you @johnpoz! you`ve made my day :)

[johnpoz]

@josifbg-0 so working for you - did you change the port, your posting showing the 192 box using 51821, but what you posted shows port 51825?

[Josifbg 0]

@johnpoz Yes, the port is changed everywhere.

[johnpoz]

@josifbg-0 glad you got it sorted not a fan really of such methods. If they want to whole punch that is fine - but there is little reason to require a specific source port - just use the port the device talked you from. This allows for napt.. But if you know what the listen port is - you don't have to use hole punching, could just port forward those ports on the different locations.

[Josifbg 0]

@johnpoz Well the main reason for hole punching is that the port can be dynamic and the second reason is not to open any ports on your router.

This way you are able to securely create private tunnels between sites without opening any ports on your router.

[johnpoz]

@josifbg-0 said in Routing from subnet does not belong to pfsense:

hole punching is that the port can be dynamic

Not when the router does napt and changes the source port - that is my point.. There is no reason for the place your talking to can't just use the port it got traffic from to hole punch back.. As in your example the client behind pfsense used port 51821, but pfsense changed that port using napt to 13355 etc.. The whole punch would of worked if the answer would of came in on that port, etc.

[moussa854]

@josifbg-0 Sorry for the late reply. I tried to replicate your setting but for some reason it did not work for me. Hope this may help others. Other user told me in the past to set the netmaker server as a relay for all of the other nodes. After doing so, you do not have to make any changes to pfsense but still able to ping and SSH to all nodes.

Firewall >> NAT >> Outbound >> automatic

No special rule in the firewall

At the Netmaker, the server node is a Relay
Done

Now I can access my home and work wherever I am at without opening any port and doing NAT'ing

[johnpoz]

@moussa854 said in Routing from subnet does not belong to pfsense:

netmaker server as a relay for all of the other nodes

In that mode all traffic would go through the tunnels the clients have setup.. No hole punching would be used.

[moussa854]

Thank you, I tested it with no hole punching and I am still able to ping all nodes. I fixed my post. Thanks @johnpoz

[falexbr]

@moussa854 I came to the same problem and after a lot of trial and error I found out that in order to UDP hole punch to work with pfsense you need to set Static Port on NAT outbound.
From the menu Firewall > NAT > Outbound select Mode = Manual and edit the auto created rule LAN to WAN and set static port.
Now everything should work ;)