Assistance enabling external access into LAN (NAT/port-forwarding)
-
Make sure you have unchecked Block private networks and loopback addresses in Interfaces > WAN
Otherwise pfSense will block any packets from 192.168.35.1 or any other RFC1918 hitting your WAN.
Why did you create this bridge?-Rico
-
@Rico
That might be it! Question though... current normal internet flow is not affected, what would be the difference? My endpoints are not being blocked from receiving all traffic from 35.1, only external requests. I will test this idea on next visit to the site.The bridge was intended as a cost-saving measure, to svoid having to add a switch for 1 or 2 extra connections needed. It did not work as intended, as traffic on different ports of the bridge would not flow across, only out. After figuring out this NAT issue, I will end up deleting it, client agreed to get the extra switch needed.
-
Firewall Rules in pfSense control what traffic is allowed to enter the Interface where the Rule is configured. So this does not affect the LAN side.
Better get any switch, even a cheap one will do better than bridging your Firewall Interfaces.
-Rico
-
Yes, the bridge is on my list of things to remove, thanks. I will test the reserved and bogon settings and report back!
-
@jkamal said in Assistance enabling external access into LAN (NAT/port-forwarding):
client agreed to get the extra switch needed
Unless you are talking high end enterprise switches - you can get very cheap switches these days even a 8 port gig smart switch that can do vlans can be had for < $50..
We just picked up some dumb 24 port netgear switches for a project that were $100.. New... If you need switch ports get a switch.. Don't waste your router interfaces to save a couple of bucks..
-
I originally wanted to balance the two 24-port switches that were in use through the router, this was the type of configuration they had prior with the Orbi router they were using prior to my adding the pfSense appliance.
The appliance has 6 ports, and at the moment, only three will end up in use -- one for WAN1, another for WAN2, and then a LAN port. The idea of the bridge was to put the other ports into use -- connect switch 1 to igb2, and switch 2 to igb3. However, I immediately realized that traffic was not working across the two ports configured in the Bridge the way I assumed it would.
Finding a use for the other ports was my objective at the time. The client has no more WANs to add, so the ports remain useless....?
-
@Rico Reporting back with interesting news.
To recap:
Prior to my attempting to install the pfSense device, there was an Orbi router that was doing port-forwarding just fine. My replacing this with my ultra-super-duper pfsense appliance was messing this external access up completely. :-)
Summarizing the situation:
There is an unknown ISP device providing a gateway of 192.168.35.1. (pf uses manual IP of 192.168.35.2)
I have pf WAN1 in igb0 as IP 192.168.35.1 (pf is on 192..168.35.2)
I have pf WAN2 in igb1 as dynamic DHCP provided ipv4. (not relevant, no external to LAN traffic here).
I have pf LAN as igb2. No more bridge. This is 192.168.2.0/24, with pofsense device having 192.168.2.60 on this network. (I have to have this set this way , client's weird network is weird and beyond the scope of this issue).I have enabled port-forward setting in system-advanced-firewall
I have reconfigured webconfigurator to use https on a new port (499) to free up port 80.
I have enabled port forwarding of port 80 to my server to internal webserver 192.168.2.103Situation: When using pfsense device, the http port 80 traffic does not get routed to my internal webserver device. When using the Orbi router instead of pfsense, it works perfectly.
And the new nugget: In desperation, I took the device home with me to do tests. I created a simulation lab:
-Connected my pf device to my cable modem (as pf WAN1).
-Reconfigured my cable modem docsis 3.0 to provide a network of 192.168.35.0/24, starting DHCP as 10.
-Enabled IIS on a PC, Windows 10, connected to the LAN port, assigned it the key IP of 192.,168.2.103
-In pf, connected WAN1 to my docsis modem, using manual IP of 192.168.2.13
-Added port forwarding rule in my docsis modem to send all port 80 traffic to 192.168.2.13AND IT BEGAN TO WORK. My IIS server is now open to the internet.
I am going to guess that there is some weirdness here that I missed in setting it up originally. So my question is, how can I configure my pfsense to act like the Orbi did, such that it would not require me to forward ports within the 35.1 network?
Thanks for any assistance, I really appreciate all your help!!
-Joseph
-
Correction to previous, in the testing lab, the ports used were:
WAN1 to doscsis modem, 192.168.35.13 foir pfdevice, gateway 192.168.35.1
port-forwarding rule in docsis modem was all port 80 traffic to 192.168.35.13.For some reason I could not edit the original post, kept getting flagged as spam by Akismet.com. Weirdness. :-)
-
To put the question more clearly, the orbi router has no problem understanding that 35.1 is sending messages to it on its port (say 35.12) without any changes in the 35.1 device. The orbi has enabled a very simple rule that sends all externally initiated port 80 traffic to my 192.168.2.103 server on port 80. How can I make the same thing happen in pfsense?
I could probably get the ISP to program similar port forwarding rules on their device, or request reconfiguration of their device to modem-only role, no dhcp or anything -- but I am trying to solve the issue without further changes.
-
I think I have it! I was using a different IP in the pfsense router, so the ISP device was not routing traffic that was inbound to my pfsense device. In other words, the Orbi was at 192.168.35.12, and I was setting my pfsense device to a different IP!!! (192.,168.35.2 and others).
I failed to visualize that the ISP device probably has a rule only for the .12 address.
Will test on my next visit onsite.
-
Confirmed issue with ISP provider, their mystery device is in fact a router and has its own port-forwarding rules. I had misconfigured pfSense to the wrong IP on the mystery boxes' network, issue resolved after configuring pfsense correctly :-)