Can I disable packet filtering while still keeping NAT to white list countries?
-
@gertjan That's what I was afraid of, we need the firewall working to white list the countries that we need, else we get so much crap SIP traffic from the internet that is unbelievable.
-
@johnpoz To be honest with you I have no clue, I only know how to do a basic setup on pfsense, install pfblocker, add the geo-ip lists and then add the port forwardings, that's about it my knowledge.
-
@paul2019 not sure what "inspection" pfsense would be doing unless your running IPS package - snort or suricata?
Its a simple layer 3 firewall - to do really any inspection of traffic and say this is bad or this is not bad from signature or something you would need to be running one of the IPS packages.
-
@johnpoz said in Can I disable packet filtering while still keeping NAT to white list countries?:
@paul2019 not sure what "inspection" pfsense would be doing unless your running IPS package - snort or suricata?
Its a simple layer 3 firewall - to do really any inspection of traffic and say this is bad or this is not bad from signature or something you would need to be running one of the IPS packages.
Gotcha, yeah I'm not running any of these packages, all I installed was pfblocker, my setup is super basic.
-
@paul2019 if DF is set on a packet that it really shouldn't be on those could get dropped I guess.
I believe there are many people around here that run sip and voip stuff that might have more experience with it than me.
Do you have these captures you could post, you sniff on wan and lan at same time to see specific if pfsense was dropping a packet and not passing it on to the lan side?
-
@johnpoz said in Can I disable packet filtering while still keeping NAT to white list countries?:
@paul2019 if DF is set on a packet that it really shouldn't be on those could get dropped I guess.
I believe there are many people around here that run sip and voip stuff that might have more experience with it than me.
Mine is unchecked, so that's correct?
-
@johnpoz We also use this setup to get the calls working correctly, do you think disabling NAT just here on the NAT Outbound entry would help?
-
@paul2019 no... Your natting a public IP? How would it work if you don't nat unless you were just routing public IP space..
Are you devices behind pfsense using public IP space? That is routed to you?
-
@johnpoz My devices are behind pfsense which is behind a router with a static public IP address.
This setup above, the netgate support helped me up with last year (I had paid support back then), when I had some issues with calls not having audio at all, after they added that entry everything worked fine. -
@paul2019 in that scenario pfsense itself was behind a nat. So pfsense was natting to some rfc1918 address that your edge router handed it..
Yeah a double nat could be very problematic to voice stuff..
-
@johnpoz Gotcha, FO100E happens to the the VOIP hardware unit here.
So this is doing double NAT?
If so then I need to check that "Do not NAT" on this entry to stop it from doing it, and see if that breaks the VOIP audio or not.
-
@paul2019 unless your isp device (edge router) is handing pfsense a public IP.. Then yeah your behind a double nat.
If its handing pfsense a public IP, and your device is getting rfc1918 from pfsense how would you turn off nat and expect anything to work.
Even if pfsense is getting rfc1918 from the edge router, is this edge router going to nat some different network? And then how would it know to send it back to pfsense? Your edge router would need to just nat anything it saw on its lan side to whatever its public Is, etc.
If they helped you last year and has been working - what exactly changed?
-
@johnpoz Yes it does handle a public IP to pfsense. The only change they did was to change the NAT to hybrid and add the entry as show above.
-
@paul2019 and your saying that was working.. So what changed?
If you disable nat and pfsense has a public IP lets say 1.2.3.4 on its wan.. And you disable nat, then it would send traffic from whatever the IP of your device is - say 192.168.1.X -- and your isp device is natting this also your public IP?
-
@johnpoz said in Can I disable packet filtering while still keeping NAT to white list countries?:
@paul2019 and your saying that was working.. So what changed?
If you disable nat and pfsense has a public IP lets say 1.2.3.4 on its wan.. And you disable nat, then it would send traffic from whatever the IP of your device is - say 192.168.1.X -- and your isp device is natting this also your public IP?
Before changing to hybrid and adding that entry it was "partially" working, some phones had audio issues and such (mute), after they added that entry above pointing to the VOIP unit local address (FO100E is an alias) the audio related issues were all solved.
We have Verizon fiber and I'm not positive how their device works, I have never logged in to it, don't even know if I can, but pfsense does have a public static ip address assigned to its WAN interface and the gateway is also a public static ip address, not a local address, this was supplied by Verizon.
-
@paul2019 I am asking what changed since they setup that no nat thing - has it been half working this whole time.. Or did something else change in your setup?
-
@johnpoz said in Can I disable packet filtering while still keeping NAT to white list countries?:
@paul2019 I am asking what changed since they setup that no nat thing - has it been half working this whole time.. Or did something else change in your setup?
As far as of the network setup nothing changed, except firmware updates on the VOIP system, which I was suspecting to be the issue in the beginning.
The random audio issues have been gone since then, no more. Then we recently noticed while digging the login the SIP 486 errors, I can't confirm they have been happening since the beginning since we did a factory reset on the unit to try to fix this.
-
@paul2019 if pfsense is in fact dropping packets its easy enough to see.. Do a sniff on wan same time you doing on one lan.. And look for packets entering the wan, but not being sent on out the lan. Or the reverse - packets coming in to lan, and not leaving the wan..
you can do this easy enough with just tcpdump on pfsense vs the gui.. you can do one in gui, and other via tcpdump via ssh to pfsense, etc.
What exactly did you send the vendor where they said the firewall was dropping packets.. If its not showing both sides of pfsense then it was a guess on their part..
Always easier to blame the customers equipment.. ;) I find it hard to believe pfsense is just randomly dropping packets, but until you have proof either way can not be ruled out. But pfsense without an IPS is not going to be "inspecting" anything and saying - oh lets drop this packet, etc.
If it was that DF set thing - you can see if DF is set on a packet coming into the wan or entering the lan, etc. in your packet capture.
-
@johnpoz said in Can I disable packet filtering while still keeping NAT to white list countries?:
@paul2019 if pfsense is in fact dropping packets its easy enough to see.. Do a sniff on wan same time you doing on one lan.. And look for packets entering the wan, but not being sent on out the lan. Or the reverse - packets coming in to lan, and not leaving the wan..
you can do this easy enough with just tcpdump on pfsense vs the gui.. you can do one in gui, and other via tcpdump via ssh to pfsense, etc.
What exactly did you send the vendor where they said the firewall was dropping packets.. If its not showing both sides of pfsense then it was a guess on their part..
I'm going to have look at this tcpdump on the pfsense today.
The VOIP unit has a built-in packet capture tool, I turned it on and let it run till the SIP error happened, then I sent the dump to them with the precise date and time the error happened.
-
@paul2019 there is no real way they can say from a sniff on their device that your firewall dropped anything.. Al they could see from sniff on their device is no answer was received.. Or they didn't get something they were expecting. How can you tell where something was dropped?
if I send a packet to 1.2.3.4 and don't get an answer - sure sniffing on my device I can see I put a packet on the wire, but got no response.. But where was it dropped, in the local network, at the firewall, in the internet some where, maybe the place I was sending it got it and just didn't answer.
To know where something is being dropped you have to be able to check on the in and out of that something that is going to process the traffic..
