Hello friends,

We solved the problem. Thank you very much for your help with Derelict  :).

The gateways of NVRs are located at 192.168.3.1. I have updated 192.168.3.254.

Goodbye.

"another 10k plus nodes."

So they have 10k some nodes all on the same layer 2 /16??  Wow just Wow!!!

From what I can make out.. Your not doing any real routing here your just port forwarding.. And all the networks on the right side are just downstream from pfsense on the left.

It should work even if a bit odd ball - but to me you are bypassing all kinds of "security" that I would assume could cause a huge stink!!!

As for a /16 LAN at home.  hehe.  So there's a couple reasons for that.  I run a business from home and often connect via VPN to my clients which are usually on a 192.168.x, but sometimes on a 10.x, and so I want to make sure I have no subnet conflicts (I realize I could do 192.168.178.x or something obscure).

Yeah, large swaths to 10. addresses are usually what you avoid if you are trying to eliminate subnet conflicts over VPNs but if that works for you…

Hi neilh23,

Thank you for your response  :)

We may put our 'extern firewalls' in separate VLAN, but I do not see how it will help.

For now we just add NAT in our extern firewalls. It works, but the drawback is that services in our DMZ do not see real source IP of incoming traffic anymore.

Regards,

Damien

The DGS-1100-08 arrived about a month ago. It sat in the US for a while, then eventually got grouped with other things and sent over. So it's a late Christmas present. I'm already ordering parts for my next project that I won't see until July. (not router related though.)

I started setting it up today and after messing with NAT and Firewall Rules the VLANS are beginning to take shape. I can finally isolate printers that ping Japan all day, a security camera system that pings China, and a VOIP box from the rest of the network.

Thanks johnpoz and Grimson for your help. Reviewing your notes on NAT was a big help.

Just to follow up. It turns out that the eBook app I was using with Calibre doesn't support SSL! I tried an alternative and it is working great with the split DNS configuration. The fix was to use the FQDN from my cert for the split DNS entry.

Thanks for the help, guys!

If NAT is not working, then who replaced source addres from 192.168.10.56 to something else?

The issue has been resolved, I went ahead and enabled the setting "Default gateway switching", based on my last observation.
Now in-spite of the WAN interface going offline the NAT works.

The ftp package is for clients behind pfsense to go to active ftp servers on the internet.. It doesn't work with active servers behind pfsense, especially ones that would have not way to get to the clients IP anyway since it has no gateway.

What that package does is look in the control channel and see the port the client is telling the server to connect to, and then forwarding that port to the client.

what???

Dude you have yet to show something wrong… Sorry but that is FACT!!!  A firewall will block out of state traffic... All the blocks you were showing were out of state.. They were not SYN blocks..

Calling it anything other than PEBKAC is what would be out of line here... Sorry been here 10 years...  If I had a nickel for every time someone said is this a bug... And bought cryptocoin with it I would be on my island with the yacht with its helicopter in the bay sipping a cold drink with my toes in the water and my ass in the sand.

Vs still here listening to people ask what is wrong, but can not provide any details to show the problem..

When you want to show us an actual problem that can not be explained by simple PEBKAC.. Then happy to help..  But sorry someone that would put a rule on interface that could never happen... Like you had shows clearly you do not understand how any of this actually works..

For future readers..  What exactly was not working here?  Other than you seeing some out of state blocks in your log?  Nat reflection??

Where is the state showing pfsense sent traffic to IP address 123 via 1:1 nat and then blocked the SA back??

Thank You!

I know this document, and I had correctly configured passive FTP ports.
I changed my firewall for pfsense and my FTP server stops work.
After reinstalling FileZilla now everithing works fine - the problem was with FTP config not with pfsense..

Sorry and thanks again.

Martin

@chpalmer:

I generally tell people to put everything back to default (no port forwards/ no static ports..)

Instead make inbound firewall rules from the SIP server to the phones behind the firewall.  You will also want firewall rules that allow the RTP streams from whichever server(s) provide those streams inbound..

Also- if your phones are going out for a provisioning files then make sure you have /system_advanced_firewall.php  TFTP proxy set for your phone interface.
I can provide some screenshots of some of my sites here if you need..

I doun't understand how I can have inbound rules to more than one phone. For example if the port is 5060, I can only forward that to one IP address right? I know I'm missing what you're saying here. Can you explain a bit further. I appreciate it.

Right. And that page specifically states to use them only if you know what you are doing and know why they are needed. They are not the "recommended settings."

I would still re-enable scrubbing and set the firewall mode from conservative back to normal. Both of those are rarely necessary as well.

I'm not sure that it's double natting due to pfSense.

I thought that the remote APs created a tunnel between the AP and the controller either local or on your intranet that's connected to the internet, is the double NAT occurring where controller is located ?

http://www.arubanetworks.com/assets/ds/DS_AP200Series.pdf

http://www.arubanetworks.com/products/networking/remote-access-points/

http://www.arubanetworks.com/assets/eo/EO_RemoteAccess.pdf

@chpalmer:

@cmb:

Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.

What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.

Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it.  :o ;D    Since I use a different port on the GUI anyways Ive never really tested it after the first time.

Not to resurrect any posts here… But I ran into the same issue as OP. Only my NAT rules were correct (as proposed by Derelict). In my experience, on PfSense 2.3.4, PF RDR does not take precedence, and will cause you to get locked out of the gui if you configure it to forward 80 to a different server. The only thing that works, is as ChPalmer describes; Change the port the WebGUI is listening on and disable the redirect, so it doesn't keep listening on 80. Then, and only then, the PF succeeds. To reflect on CMB; It was not a browser cache in my case. For the OP's 'other' issue; You probably forgot to open 80 somewhere on your destination server (or along the route).

Why this comment?
If PF RDR should take precedence always, which would be a great feature, it is not working. Maybe a bug fix is in order.

Thanks all.

Ok so now to figure out why changing the router would cause the server to reject the connection… I made no changes on that side.

Is the current subnet routed? If so then just subnet it.

Break it into 2 /28 you can use 1 as vips on wan for 1:1 and use the other /28 for behind.  Or /28 and 2 /29's… How ever you want to break it up... But your /27 actually needs to be routed to you.. Not just you attached to it.

So you have another transit network and this /27 is routed down that transit.  If so then yeah this is easy peasy lemon squeezy..