Is this happening to anyone else? Not that I am aware of. any ideas? You've given us nothing in the way of details.  I'm not even clear if you're talking about people incoming getting the wrong server from your network, or your LAN clients going to some external website and getting something else.  List the packages you're using.  Explain exactly what's happening and not just a vague, abstracted description.

If someone remote must access the SQL server, make them use a VPN to do it. Never expose any database directly to the world.

You have setup NAT for everything you need, but L2TP+IPsec is known to have problem in general (not related to pfSense) when the server is behind NAT. Use something more modern and less problematic, such as IKEv2, or if you need the server to be Windows, SSTP might be able to work as well, though it can also have NAT issues.

Hello my friend I'm Sorry if I'm Bothering you , but I'm new with the GnuGk and with Pfsense thats why I'm  facing  problems in order to make the call establishment between two end devices one is behind LAN network and the other behind the WAN  network. Sorry maybe I didn't understand what is your network and how you did configured it , did you register your device  with your GnuGk installed in the pfsense or you Register it in another place, I believe that to establish a call between 2 end devices they must be registered with the same Gatekeeper so that the Gatekeeper will route make the call establishment between the 2 users since it will know the IP and ext. number  for both end devices. Actually I have some questions beyond your suggested solution and I found that  your solution does make sense , so I need your help and I need to benefit from your experience if there is no problem :) 1-where did you Register your devices , if you have 2 devices one behind the firewall and the other is outside your network and they want to call each other , do they need to be registered with the GnuGk ? 2-what is the benefit of installing GnuGk in the pfsense 3-Can you show me your GnuGk configuration file because I think I missing something 4- You said in your report that If someone phoned from an external device to your device, dialing must be: your IP##ext number such as 8.8.8.8##5693 where I should configure this option so that I can Dial using this syntax. Thank you for your appreciative efforts :)

Ohh, of course, it would be in connection with the tunnel rather than NAT.  :-[ Thanks! Appreciate it. :D

I figured it out. My 1:1 NAT rule for 192.168.230.8 had NAT Reflection set to Enabled, whereas the 1:1 NAT rule for 192.168.230.190 has NAT Reflect set to System Default. As soon as I switched it to Enabled, things started working. :)

Some mornings it's just not worth getting out of bed. Thanks to both of you, I have it working. Gerald

@Derelict: Yeah that's not at all how it works. Put your VIP and outbound NAT rule on the outbound interface. OPT2 in this case if I am understanding correctly. Thank you! That worked perfectly first time - after all this time of banging my head. In case anyone else is looking, this is what I did: 1. Set up a virtual IP of type "IP alias" (but perhaps some other types would have worked just as well) with the IP that I want the packet to look like it came from (192.168.2.10 in this example). The IP alias is set on the interface it will leave the router on, not the one it arrives into the router at (OPT2 in this example). 2. Set hybrid NAT (or if you prefer Manual/AON) and then add an Outbound NAT rule again on the same interface the packet will leave on (OPT2) with source = any (or whatever IP range the packet actually came from) and dest = the destination IP or its subnet or whatever (I used 192.168.2.0/24). Then set the translation address by choosing the virtual IP from step 1, in the drop-down box. As far as I understand it in lay-terms, the misunderstanding is that outbound NAT seems to mean "outbound from the router", not "outbound from a given network into the router". Ambiguity of language, but what a headache. The packet, sent to its destination IP, travels in from OPT1 and is picked up by NAT when it's outgoing at OPT2 (the interface in the NAT rule). As the packet's src matches "any" and its dest matches the value entered in the NAT rule (192.168.2.0/24), its source is translated to be 192.168.2.10 as required. Packet capture confirms it - when I ping as described in the 1st post, packet capture on the OPT1 interface shows a ping and reply from 192.168.1.2 -> 192.168.2.2, but packet capture on the OPT2 interface shows a ping and reply from 192.168.2.10 -> 192.168.2.2 as desired. Thank you very much indeed. (Maybe this could be made clearer in the documentation as well?)

Pretty sure that NAT will have to be done on the other side. BINAT in a phase 2 translates the network on your side as it appears to the other side. You would set up a Phase 2 for 10.2.0.0/16 to 10.3.0.0/16. They would NAT it from 10.3.0.0/16 to 10.1.0.0/16.

Here's a more appropriate link. https://forum.pfsense.org/index.php?action=search&advanced&search=Please%20match%20%20the%20requested%20format&sort=id_msg%7Cdesc;

Hi there, it seems that this error is caused because the same source (128.140.150.200:5060) is sending packets to two different ports. I've asked IPDirections to start the communication directly on 65002, which means all communication from port 128.140.150.200:5060 is send to 65002. That did the trick, now all packets gets through to my PBX. For me this issue is solved with a workaround, however I still believe  this is an pfsense/FreeBSD issue. Many thanks for assistance! Chris

Depending on what you're using for internal DNS, you would either create a new zone for your external domain and then just add some A records to it that point to your internal servers local addresses.  If you're using pfSense then you can just add a couple of host overrides.

What does that have to do with using pfsense with a bridge.. So you can not run speedtest from your client that your currently connected too.  I don't understand how pfsense be it in a normal nat routing setup or a bridge setup tells you how much bandwidth your ISP is giving you??  Sure you can see how fast a client is pulling/pushing packets to your isp and beyond.  But you can do that on the client as well. Here let me help you out http://speedtest.net http://speedof.me/ https://www.verizon.com/speedtest/ http://www.att.com/speedtest/ https://www.speakeasy.net/speedtest/ http://www.dslreports.com/speedtest many many more..

Extra info: We have tested this again. When calling trough the site-to-site VPN connection everything goes well.

@Derelict: #5 on this list: https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting Agreed, I just never thought it would be used by them for device control and I haven't always had the wireless receivers, and 443 has worked for me in the past.

So… After rebooting the firewall, looks like the issue has fixed itself.  If I had to take a guess, even with the process restarts and the session tables being cleared, it was not applying the NAT to the running configs.  Guess my concerns is that I'd have to take an outage like this for changing advanced NAT settings, which shouldn't be an issue in a home environment.  Thread can probably be closed, unless someone would like to discuss. -Tom