Open states will stay open. They will need to be closed, expired, or otherwise killed/reset to point to the new server.

It was something in the setup process.

I'll look at it again sometime.

@derelict
https://puu.sh/BGisz/cf24c96a73.png WAN up
https://puu.sh/BGisc/2fcf7bcb35.png WAN down

I figured it out! My Fios router was blocking the ports. I put my pfsense router's ip into the DMZ on the fios router and all port rules forwarding worked!

Here in the UK that's exactlky how I have this setup at home. VLAN over a LAGG group to a switch. The VLAN is untagged at the switch and connected to a VDSL2 "modem". The PPP session runs over the VLAN to the modem, v6 comes up using dhvpv6 over the pppoe session.

The "modem" device is in fact a Huawei router in bridge modem supplied that way and locked by default.

Steve

@jimp Thanks, it seems to be a rules of Snort (that I have deleted) that cause problem. I'll try to reboot the system.

EDIT: I have solved according to this guide: https://forum.netgate.com/topic/119115/block-snort2c-hosts-blocking-http-traffic-for-lan-clients/2

Using Flowroute's host routing (no SIP registration / routing), I apparently needed to enable Ans Call Without Reg in the section Proxy and Registration on the SPA8000 trunks (on lines, if I were routing to individual lines) in question.
Inbound calls are now working as expected.

Yes, you can set a source IP (or an alias containing several IPs) in either the port forward directly or in the firewall rule filtering traffic forwarded by it.

Steve

You sir are my new best freind THANKS SOOOOOOOOO MUCH! :D

It was trying to route everything out a Management VLAN at our Provider :)

Looks like it also fixed some of our VPN issues and other things. Hope this thread helps someone who may also be in the same situation.

GREAT !!! THANKS !!!

@rico said in DMZ server not getting the internet:

Wow, this is a lot of Youtube tabs.

And that's exactly the problem. People only replicate what others (oftentimes with shady knowledge) show on YT. They don't read manuals or docs anymore and try to understand how it's working.
And the result is a not working config without the slightest cue where to look and how to solve it.

@surajitit said in DMZ server not getting the internet:

Need help as soon as possible.

Really? ASAP is here: https://www.netgate.com/support/

Ok that EXPLAINS it ;) your "gateway" is the IP of your isp device, ie the device you talk to when you get to the internet - its their router your router is connected too..

So yes that octet would be different but would be in the same network.

As to not pushing traffic through your vpn - make sure you do not pull routes in the client config, and then just policy route what you want to go through the vpn.

Ok, so in this configuration it seems that the best solution is to create a second VM running on the same physical NIC as the LAN connection. I launched a Fedora VM, configured a second NIC reaching to the first VM as the gateway and immediately gained access to the webConfigurator.

Anyone have an idea as to why this doesn't work from the host machine?

Hi,

While I have found a work-around in this particular instance - by reducing the header information in the SIP request, anyone sending UDP out on a WAN with a lower MTU than the LAN might run into this issue. This might affect VPN links as well as VOIP. Typically intranet LANs run 1500 byte MTU and VDSL/Fibre can often have a slightly smaller MTU.

If you do have an issue with WAN outbound UDP, running tcpdump on the WAN leg and loading the file into wireshark to look for the source address being transmitted out of the firewall.
0_1537861986638_b7c16e8e-6480-442a-a494-9ccc0254be79-image.png
If you see the LAN source address, then you have the issue.
There may be a config setting that will change the behaviour, however if this cannot be found,the packets will be dropped by the first internet router that sees them as private non-routable addresses are just that.
Regards
Simon

I figured it out. I needed to use 1:1 NAT for the routers ip.

The 1:1 page is for the inbound connection.

It can get crossed up if you do that manually, so traffic comes in one IP and the reply is sent out another. That generally doesn't work since the other end drops the reply packets.

I'm pretty sure pfSense will just automatically do it right. If you can connect out from the servers using 1:1 then connect out to whatismyip.org or something and you can see what IP you're connecting out on.

On the outbound page what I was trying to say was that any rules entered there are processed in order, like firewall rules.