Allow only outbound connections to one ext. IP and port
-
@CreationGuy looks like the blueiris server is trying to resolve dns queries to the firewall. If you intended to use the firewall's unbound as the blueiris dns resolver then add an allow to the firewall on ports 53 and 853, otherwise, you'll have to hard-code a few public resolvers on the blueiris and then add an allow rule to those same ports to those resolver destination IPs.
-
@NickD-0
Why do I need to us DNS when APNS uses IP? I don't want to open DNS to this VLAN if I can avoid it. -
@CreationGuy It's near certain those system in that vlan will need some amount of outbound dns resolution to work properly. The blueiris server is likely trying to resolve the apple apns services by a hostname and not a hard-coded ip. There are other applications on that server that likely need dns beyond just apns: patches, firmware checks, endpoint protection updates, etc. You might want to allow that NVR_Allow rule then get it all working and then do a packet capture for a few minutes. After that you can download the capture and analyze exactly what ports and services are needed outbound so you can further restrict that rule. Apple's apns needs a specific set of ports outbound allowed to work properly. The Blueiris server might need more beyond that but I'm unfamiliar with that product.
-
@CreationGuy it’s looking for your DNS create a nat rule and direct the device to where your dns resides. You have no dns rules I see. The system needs to know where the router is. Just direct the dns to the firewall
-
@JonathanLee If I enable DNS, won't that allow devices to make outbound DNS requests and get out to the internet?
-
@CreationGuy I have the firewall do the DNS requests so I have a nat rule that directs any dns request to the firewall that handles the requests.
-
@CreationGuy said in Allow only outbound connections to one ext. IP and port:
Why do I need to us DNS when APNS uses IP?
You don't.
But 'some software' on the device with the IP 10.90.90.2 really want to resolve something and uses pfSense (probably 10.90.90.1).
And you've forbidden that.If that's ok for you, its ok for me ^^
Still, normally, 10.90.90.2 is only asking something from 10.90.90.1 (pfSense) and you trust pfSense, so let it have 10.90.90.2 his DNS, as, imho, this can't be a real risk.I advise you to add a non-logging blocking firewall that expressly blocks DNS traffic to "10.90.90.1" port 53 proto UDP. Dis will clean up the main firewall logs a lot, so you can spot more easily the other blocked requests.
@CreationGuy said in Allow only outbound connections to one ext. IP and port:
If I enable DNS, won't that allow devices to make outbound DNS requests and get out to the internet?
You can also create a firewall rule that permits DNS access to pfSense, 10.90.90.1 (port 53 - TCP and UDP ) and on a next rule you block with - all destinations - all other DNS requests. From then on, your 10.90.90.2 can do DNS to pfSense and no where else.
-
@Gertjan said in Allow only outbound connections to one ext. IP and port:
@CreationGuy said in Allow only outbound connections to one ext. IP and port:
Why do I need to us DNS when APNS uses IP?
You don't.
But 'some software' on the device with the IP 10.90.90.2 really want to resolve something and uses pfSense (probably 10.90.90.1).
And you've forbidden that.If that's ok for you, its ok for me ^^
Still, normally, 10.90.90.2 is only asking something from 10.90.90.1 (pfSense) and you trust pfSense, so let it have 10.90.90.2 his DNS, as, imho, this can't be a real risk.I advise you to add a non-logging blocking firewall that expressly blocks DNS traffic to "10.90.90.1" port 53 proto UDP. Dis will clean up the main firewall logs a lot, so you can spot more easily the other blocked requests.
@CreationGuy said in Allow only outbound connections to one ext. IP and port:
If I enable DNS, won't that allow devices to make outbound DNS requests and get out to the internet?
You can also create a firewall rule that permits DNS access to pfSense, 10.90.90.1 (port 53 - TCP and UDP ) and on a next rule you block with - all destinations - all other DNS requests. From then on, your 10.90.90.2 can do DNS to pfSense and no where else.
I appreciate your information. I decided to allow the NVR (10.90.90.2) to make DNS requests to the pfSense and no internet access. See the screen shot below, Apple notifications are working now for camera alerts. my phone will only get alerts when home or on VPN (I may decide to open this up so I don't need VPN at some point but is not a huge deal ATM).
I temporarily enabled logged for the DNS rule:
Does this look like what you're talking about?
-
Look ok.
In the green Allow section, after each pass (green) rule, add an explicit block rule.Where you make it a Block and non log rule, and remove the "CAMLAN Address" destination.
From now on, identified DNS traffic from the "NVR" passes to pfSense, and no where else.
Do this also for the NTP rule.
Maybe also for the "APNS rule".When done, your firewall log will not be polluted with this known traffic.
Suspicious traffic will show up easier as the log get less filled up.And when all is well, after some time, you can uncheck :
as 'rubbish' doesn't need to be logged ^^
-
@Gertjan said in Allow only outbound connections to one ext. IP and port:
@CreationGuy
And when all is well, after some time, you can uncheck :as 'rubbish' doesn't need to be logged ^^
Thank you - I was wondering if there was a setting to disable the default block rules, it's good to have for some troubleshooting, but there's a lot of entries for it that I don't need, generally.
edit: although, I do like to see the external attempts on getting into the router...
-
@CreationGuy said in Allow only outbound connections to one ext. IP and port:
edit: although, I do like to see the external attempts on getting into the router...
Wrong ...
That would be like looking in the barrel of a gun to see if a cartridge (bullet) is loaded.
Not the best way of checking things.Every blocked packet will match the default block rule .... that's ok, and can be done rather quickly, but if every blocked packet also needs to be written out in a file - the firewall log, then every blocked packet will use loads of CPU cycles.
If 'they' know that you are doing that, they will ramp up the traffic quickly - this is what DOS is, your log file will fill up very quickly, your pfSense will get hot and goto "100 % CPU usage" , and if a log file rotating goes wrong your disk start to fill up => bommmmm assured.
Is your disk an emmc (see other forum threads) ? Your disk will be dead in the near future => another boomm.Apply the good old rule : keep a low profile and nobody will knock on your WAN door.
After all, your WAN interface is probably constantly probed for possible allowed in-going connections. You can't stop ** that. It's part of the Internet. See it as the back ground noise.
It's like living in a huge building with many front doors : kids are constantly pulling your door bell. Up to you to stay alert behind the door to see who is ringing ....Even worse : if you get DOSsed, there is only one thing you can do : call your ISP and make "them" (the dossers) stop. They'll tell you they can't ... but they can pull the plug for you - or you pull the plug yourself = remove the WAN cable for a moment.
Or wait it out you doing nothing, pfSense can handle it : black-holing traffic is easy, you are after all limited to the bandwidth you have.Actually, you can : put a firewall in front of your firewall.
So, ok to have a look at what happens at the WAN gate ones in a while, just don't forget to stop logging when your done.
edit : If your pfSense is behind a (CG)NAT or your ISP router : you won't see anything on WAN, as the upstream firewall / router / NAT device already took the bullet for you.