It's basically not a good idea to expose a NAS to the internet at all. However, that's your decision.
I suspect the issue won't rather be the NAS itself than the firewall rule or the port. I guess, the Synology might block access from IPs outside of its own subnet.
You will have to allow that on the NAS itself.
I take it all back. This is nothing to do with NAT. After purchasing a second static IP address and creating a set of completely stateless rules (a story in itself) I find that the problem still occurs. Rapidly opening many connections, to many destinations causes huge spikes in packet loss and latency which correlate only to a rise in system CPU usage. Though this rise is only from a base level of ~1% utilization up to a maximum of 7% utilization, so it should not itself be causing the issue.
I can't find any other metric that is even remotely stressed.
@j-lanham You're welcome. Also after (re)installing pfB you might need to run an update to generate the aliases.
I am not sure why there are two packages. I suspect the -devel started out as "beta" but then everyone started using it, and now people would have to uninstall it to install the original. -devel version 2.x existed long before 3. The author has a Patreon site at http://pfblockerng.com/ but it doesn't really explain that.
You say this because you've looked at the firewall logs and you saw the incoming (WAN) traffic - with the correct (8096) port and correct "protocol TCP" being flagged as 'blocked' ?
I give you an example :
I have a Synology Diskstation in my LAN, it has IPv4 192.168.1.33 (RFC1918 of course).
I've created an alias for the device name "diskstation2", it resolves to 192.168.1.33.
I want to access my Diskstation using https://diskatation2.my-domain.tld:8080
I created a NAT rule :
The 'destination' is the firewall macro WAN Address, as my WAN is is always part of WAN address. The day my WAN IP changes, my rule still works.
I want to reach my diskskation on port 8080, so "Destination port range" is set to 8080.
The traffic that comes in and matches WAN Address & port 8080 should go to :
Redirect target IP : I entered the Alias "diskstation2", I could also enter "192.168.1.30".
And the destination port : my diskstation web server listens on "443", it's using TLS.
I have a NAT rule :
I checked the auto created WAN firewall rule :
I tested with my phone ( with Wifi shut down !! ) , and entered :
I saw the main web page of the web server of my diskstation2.
I also saw :
which means that the WAN rule was used / matches incoming traffic. That was me testing the access with my phone..
If needed, abuse the pfSense documentation, like Port Forwards. Port forwarding or port NATting or, more correct, PATting, hasn't changed since 1995. Every Home/business router/firewall needs the same inputs. pfSEnse seems to be diffrent but check for yourself : you have to enter 4 things, and your good. The rest of the option are 'special cases'. The day you need them, you'll know they are there.
Also : I copied all the images without the need of masking something. The correct use of aliases and firewall macros make rules maintenance easy : It becomes a "set it and forget it" which means I had to look up the pfSense NAT doc, as I tend to forget things. I do not use NAT rules any more, only a VPN access which is just a firewall rule, no NAT). Exposing internal devices in a company network is a big no no (imho). This said : this is also valid for you : now your 192.168.1.250 becomes part of your network security. Keep that in mind.
Yes, that was what I thought, and the question initially was regarding why it was not working. But I've found the problem now. I've set it, in the general setting, but NAT Reflection was set individually on each NAT rule. So changes here had no real affect.
In the OpenVPN client settings check "Don't pull routes" to permit the client to set the default route.
Assign an interface to the vpn client instance and enable it if you didn't already.
Then add a policy routing firewall rule to the internal interface. Enter the source IP or an alias for multiple if you want to specify. At destination leave the address at any and enter the destination port range.
Expand the advanced options and select the VPN gateway.
Put this rule to the top of the rule set so that it matches first.
I assume, you your outbound NAT is already set to work with the VPN.
To verify that the packets go out on the VPN interface, you can sniff the traffic using the packet capture tool on pfSense, while you try a connection to the concerned ports.
To ensure that nothing goes out to WAN you can add a floating block rule for direction out with Quick checked and state the ports in regards.
Thank you for the information, I did in fact have the P2 local network defined as the subnet on within the local LAN assuming the routing would have still sent the traffic across based on the destination IP and the routing table however that obviously didn't end up being the case. After changing the local network on the P2 from 192.168.1.0/24 to 0.0.0.0/0 the traffic started sending across the tunnel.
So after tons of testing I think I can say it's the GeoIP causing the issue,
Not sure why, and it's not consistent 100% of the time,
But when Floating rules are enabled (and the interfaces are selected in inbound and outbound) and GeoIP is enabled as Deny Inbound, the issue exist.
I wasn't able to reproduce the issue when Floating Rules was disabled.
Sometimes even if Floating Rules was enabled and GeoIp was enabled then it worked (for example when changing the Floating Rules from disable to enable while GeoIp was enabled, it worked sometimes and no issue existed.
Only if i disabled all GeoIp, forced PfBlocker to reload all rules (under Update), Enabled GeoIp, forced reload again then the issue happened I think every time.
It also seems like for me, while I live in Israel (which is part of Asia Alias), Europe GeoIp caused more for the issue to happen, even if only one country from that filter was selected.
I know it's not 100% step by step on how to re-produce the bug but that's what I managed to gather so far, hope it's enough.
Yup, he could add the static route on 192.168.1.17.
Yeah if your going to have hosts on your transit you would need to do host routing.. Its a hack, not a true setup anyone should want. When its simple enough to set it up correctly.
To be honest you would almost never actually want/need a downstream router, your going the wrong direction that way to be honest. Just replace your edge with pfsense, use your old wifi router as just an AP as the transition phase until you can get AP that allow vlan and switches that can as well if you want to setup a real network ;)
Yes in a large enterprise network you would see routing done internally all the time vs just at the edge.. But in a small network or home or home with lab setup just doesn't really make sense other than a learning experience. And if your wanting to learn, then do it correctly with a transit network.. Sure if you want to play with why it doesn't work when you have hosts on a transit and the asymmetrical traffic flow that will result - sure have at it.. But I would set it up correctly, then break it with putting hosts on your transit and see why the asymmetrical flow is not good when you have stateful firewalls also in play..
Yes I created the Site-to-Site IPSec with NAT'ing using this link. The tunnel is UP together with Phase 2. I can also see traffic from Site A to Site B. When it enters the Site B and I do a packet capture, I can see the the NAT IP addresses.
For the installation, I would like to access the new virtual network from the LAN
You have two different LANs. Guess you mean this one 192.168.24.0/24.
Is there a way to set up a redirection on the 'old' pfSense so that all calls for 192.168.83.0/24 from the network 192.168.24.0/24 are routed to the WAN IP of the 'new' pfSense (192.168.24.20)?
Really not clear, why you want to do that. But yes, that's doable with a simple port forwarding rule, presupposed the old pfSense is the default gateway in the LAN.
However, since both source and redirect target are within the same subnet, you need to masquerade the source IP.
For masquerading add a rule in Firewall > NAT > outbound. If the outbound NAT is in automatic mode, switch into hybrid mode and save this first.
Then add a new rule:
source: LAN net
translation: interface address (or LAN CARP VIP if any)
redirect target: 192.168.24.20
I propose a last resort test :
Double check that your daily config backup of pfSense is ok.
Now, as usuall : reset pfSense to default.
Accept de fault settings, never aver add a setting, like a DNS server (not needed) - just a WAn and a (one) VAN - stay away from VLANs. Nothing fancy - just the "out of the box" settings.
One exception : you are allowed to change the GUI password.
Now, phone an the LAN. The 192.168.1.1/24 LAN
Doorbell on the 192.1681.1/24 LAN.
Nothing else has to been do on pfSense - as per Doorbell Quick instructions guide.
Btw : Now you have created a pfSense like as any other router/firewall you got from your ISP ... it is and behaves as all the other firewalls on planet earth.
Right now, you could inter change your ISP router with pfSense, and have a working LAN network.
If a device doesn't work right now out of the box, you know it is the device.
Can't make it work => don't waste your time - waste-bin it.
Btw : setting pfSense to default isn't fool proof.
Just count those who set up their LAN like this :
and then complain "the DHCP server doesn't work"...... (no pool available).
Or they assign a gateway to the LAN settings ..... (same image)..
It's quite simple. Post you 1:1 rule please.
For troubleshooting use Diagnostic > Packet Capture.
Sniff the traffic on WAN. Check out the IPs of www.myip.com and enter them in the Host box (multiple separated by "|").
Start the capture and try to access www.myip.com from the internal device.
You should see the packets going out with the source IP you stated at external in the 1:1 NAT rule.
Also consider the option to set up a second OpenVPN connection. I'm thinking to run the server on the VPS, since it has a static IP.
However, the rule setup I mentioned above has to be exactly the same.
I was assuming, you need incoming connections only on the SMTP server. If you also need outbound using the VPS IP, you have to configure a CSO for the VPS client on the home pfSense, when using only one (multi purpose) server to let OpenVPN know the proper route. And you will have to policy route the servers outbound connections to the remote site.
Additionally on the VPS you would need an outbound NAT rule for the SMTP server.