UDP Hole Punching

mobydick426

Hi all,

(I'm using latest version of pfSense)

I've a private server with a 1:1 NAT, but without any incomming rules enabled in pfSense.

To access this private server from any remote computer, there is a client who can connect using port 443 or UDP Hole Punching.

During our tests, we realize that connections are successfull without any rules enabled/created because of UDP Hole Punching.

Can you help me understanding why this is possible ?

I thinked that rules are in front of any traffic between external computers/servers and our private servers.

But it seems that some traffic is possible whever no rule are defined !

How can I force UDP Hole Punching working only if a specific UDP rule is created ?

Thanks for your help/explanation

Regards,

kiokoman

@mobydick426 said in UDP Hole Punching:

During our tests, we realize that connections are successfull without any rules enabled/created

pfSense is a stateful firewall, which means it remembers information about connections flowing through the firewall, the data is retained in the State Table
resetting the state table is the only way to make sure all connections respect the new ruleset
did you kill/reset the state table after editing the rules?

https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html#stateful-filtering
https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-reset.html#reset-state-table-source-tracking-table

Gertjan

@kiokoman : even when they are not

@mobydick426 said in UDP Hole Punching:

created

Not created means to me me : no states could exist.
Or maybe a (gone now) WAN firewall rule was hiding another WAN firewall rule - they overlapped ?

1:1 NAT : looks scary to me. Everything is natted to a device, but WAN firewall rules still apply ?
A couple of classic NAT rules look better to me.

mobydick426

@kiokoman : thanks for your reply. Tests have been made since some months ago. But rules was disabled (or deleted) and the firewall has been restarted many times for different reason.
So I don't think that any state are or was available on pfSense.

mobydick426

@Gertjan : thanks for your reply. We use 1:1 NAT on many firewalls and servers without any problem. What do you mean by "looks scary for me" ?
Your question is interresting but no, no other existing rules can explain this.
We use 1:1 to not have identical rules for many servers (no global rules).

kiokoman

even with nat 1:1 you need firewall rules to permit traffic, you only need to be more careful with rules. but other than that there shouldn't be any problems

Gertjan

@mobydick426 said in UDP Hole Punching:

What do you mean by "looks scary for me" ?

You're right to ask for clarification.
I never used 1:1: NAT . That's all.

mobydick426

@kiokoman Thanks for your reply and sorry for my late reply.

That's the reason of this topic.

We had never rules allowed, only 1:1 NAT defined.

And we have noted that traffic was accepted by pfSense !!

So why and how to impose rules for all traffic ?

Regards,

kiokoman

@mobydick426
uhm i've made some tests and nothing is passing without a firewall rule
tcp client is blocked, udp also

Dec 7 15:23:17	WAN	USER_RULE (1559836757)	  93.36.17.251:36738	  217.133.xx.xxx:48570	UDP
Dec 7 15:23:14	WAN	USER_RULE (1559836757)	  93.xx.xx.251:36738	  217.133.xx.xxx:48570	UDP
Dec 7 15:23:02	WAN	USER_RULE (1559836757)	  93.xx.xx.251:36738	  217.133.xx.xxx:48570	UDP
Dec 7 15:14:31	WAN	USER_RULE (1559836757)	  93.xx.xx.251:36228	  217.133.xx.xxx:48569	TCP:S
Dec 7 15:14:28	WAN	USER_RULE (1559836757)	  93.xx.xx.251:36162	  217.133.xx.xxx:48569	TCP:S