@JonathanLee said in OpenVPN TAP firewall rules.: @Jarhead any any rules scare me you got to know at lease a source or destination Exactly my point. What would the destination be when it's the same subnet as the source? The only difference is it's going through the vpn tunnel but the other side is still the same subnet because it's a tap tunnel. I would think it wouldn't need any rules.

@JamesBCSD said in Allow traffic from port 0 from a specific IP address: replaced the router with pfSense that makes sense then - routers not going to care what source and destination ports in play - its just routing ;) Yeah its possible you could pick up a little mini pc refurbished for cheaper than a pi.. Mine sure are not fastest horse in the stable that is for sure.. More like the slowest/oldest mule inline to the glue factory dragging its feet because it knows where its headed.. But it can do what want it to do ;) Sure wouldn't need much to run syslog in relay mode that is for sure.. A pi zero would prob be all you would need.

@Gertjan It was a real issue and it's this is the Snort rules that generated it spotted it, I think that because it is a home network the bad guys assumed they could get away with it and pfSense plus stopped it cold and gave me the logs to report them. I have it on the WAN side the rules below. # === VPN SECURITY (OpenVPN UDP 1194) === # NOTE: Port corrected from 1192 to 1194 to match actual firewall # VPN connection from non-Approved source alert udp !approved source any -> MY IP1194 (msg:"CRITICAL: VPN Connection from Non-Approved Source"; classtype:policy-violation; priority:1; sid:1000010; rev:2;) # VPN brute force from MetroPCS alert udp approved source any -> MY IP1194 (msg:"OpenVPN Brute Force from MetroPCS"; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:1000011; rev:2;) # VPN connection flood (DoS) alert udp !Approved source any -> My IP 1194 (msg:"OpenVPN Connection Flood"; threshold:type threshold, track by_src, count 50, seconds 10; classtype:attempted-dos; sid:1000012; rev:2;) # OpenVPN malformed packet alert udp any any -> My IP 1194 (msg:"Malformed OpenVPN Packet"; dsize:<14; classtype:protocol-command-decode; sid:1000013; rev:2;) I reported it to IC3 and someone actually called me said it was really good stuff that I had, that it is a big problem in our area the last 8 or so months I think he said. This firewall caught something and it contributed to local cyber security. After he called, I have not seen as many of them anymore also. I also reported it to Digital Ocean and they responded to my report and thanked me for it. I have never had someone call me about a report before. The data was the combination of how many attempts and what was occurring they must have seen it before, maybe if you guys see vpn attempts from them we should start to report at least the VPNs that is like breaking and entering its no longer scans at that point. I feel like we see so much noise that when we start to see something that is real it get questioned, I was even thinking it was nothing, but they kept doing it.

@mohiuodin1 For returning traffic you don't need a WAN rule. Normally, when traffic is allowed to go out, from LAN to WAN, the related returning traffic is allowed to get back into the WAN, to be send to the device on the LAN network. That's what state-full fire-walling is all about (my words). That said, the 'kernel' has to recognize the send (from LAN to WAN) traffic, so it can match, recognize the returning traffic. If it can't, it will handle WAN incoming (the return) traffic as 'not related', and it will block it. I saw the github main page, and the "iptables" examples, where iptables was instructed to do 'close to nothing' (my words) with the packets, as 'raw' option is needed. The kernel (Mac, Windows or Linux- not FreebSD !!) is even told to disable auto generated RST packets. The fact that no FreeBSD pf instructions (options) are given could mean : "don't even bother, it's a no go (for the moment)".

@Cabledude said in Packet Loss and Connection Drops During Local VLAN File Transfers (High CPU): @keyser Have you had the time to check if the issue is still there? I have an SG-2100 and I am very interested in hearing about this. FTR I upgraded to 25.11.1 yesterday. Thanks, Pete I have just tried to replicate the problem, and I have been unable to do so. However: I’m not intirely sure I have the same ISO files to testcopy with (Some have been replaced by a newer version). So I cannot guarantee it 100% because if it is a VERY specific bytepattern, then there is a risk these test ISOs does not have the same. But, I have tried with 20 different ISO’s and all sorts of other files, and I cannot replicate it, and before it would die with 100% certainty using several of the ISO’s I had at that time.

@johnpoz I feel you like it's like a puzzle, plus you find stuff you didn't know was going on this way.

@giles.pj The protocol on your rule should be IGMP. Destination address should be Any.

Playing on a live firewall isn't a great idea. But, but—that's like what I do every single day...?

@zemerdon Why not just use pfBlockerNG to do it? This post is over a decade old and likely predates this exact functionality being added to the package.

I agree handle one issue at a time, not working on any port forwarding until workstations can get to internet Keith

@tinfoilmatt said in Rule with UDP and port 514 not matched: Mess not clear. Do you nedd some specific logs. Rule i not matched if UDP prottocol is used.

@johnpoz Cool!

@SteveITS Thanks for your response pal, this input has helped me resolve the issue. Sounds obvious now but this was resolved by disabling the outbound NAT policy for web host subnet behind the firewall. Now the source IP remains the same so on the ping reply it reachs the web host as final destination, not the NAT IP on the pfsense.

@patient0 Thank you for that information.

@luckman212 The 20.1.0.x network is coming from my pfSense OpenVPN server tunnel network. I initially had it configured as 20.1.0.0/24, but I have since changed it to 10.4.1.0/24 and the behavior is still the same. There is also an explicit outbound firewall rule on pfSense that prevents the VPN tunnel network from egressing to WAN, so 20.1.0.x is not leaking to the public internet even when it was in use. This address space only existed internally on the VPN tunnel. -- Current topology: pfSense OpenVPN tunnel network is 10.4.1.0/24, pfSense side is 10.4.1.1 and EdgeRouter is 10.4.1.2. From the pfSense LAN I can ping 10.4.1.2 successfully, and from the EdgeRouter firewall I can ping the pfSense LAN network 192.168.0.0/24 without issues. Firewall to firewall connectivity works, but end hosts cannot reach each other. For example, host 192.168.255.2 cannot ping 192.168.0.14, and hosts in 192.168.0.0/24 also cannot reach 192.168.255.2. However, both firewalls themselves can ping devices across the tunnel. Hosts in the pfSense network cannot reach 192.168.255.0/24 behind the EdgeRouter. The only variable that changed is a pfSense upgrade, this setup worked correctly on an earlier version but stopped working after upgrading to 25.x. pfSense LAN 192.168.0.0/24 | | [ pfSense ] LAN 192.168.0.1 VPN 10.4.1.1 | | OpenVPN tunnel 10.4.1.0/24 | VPN 10.4.1.2 [ EdgeRouter ] | | EdgeRouter LAN 192.168.255.0/24 | Host 192.168.255.2

@Spider_VL This is a really helpful resource! Thank you for sharing it. I think I’ll refer to this diagram whenever I get confused while working in the lab. Understanding how direction works in floating has been really challenging for me, so I’ll study it more using this figure. Thanks again.

@KOM Thanks for the speedy reply mate. Yeah, ive had a brief look through the xml and it looks pretty good to edit. Im thinking ill be able to just replace the quad port rj45 with the quad port sfp, adjust the interface names and up and running.

@MP83 FWIW Netgate doesn't date stamp releases but the order can be seen in the left navigation pane of https://docs.netgate.com/pfsense/en/latest/releases/. 25.11 changed FreeBSD versions (to 16), presumably why the fix was included in this case. Edit: dates are on https://docs.netgate.com/pfsense/en/latest/releases/versions.html, d'oh, I knew that.

@johnpoz I set those in the past (long time ago) from the firewall logs because of the same behavior when they were getting blocked. I'll disable for now and see what happens.