First, like what Steve mentioned in his reply, I hope that the addresses
are a typo and you meant 192.168 Using an address block that belongs to
someone else instead of the standard private address blocks (or an address
block that was assigned to you) is a recipe for disaster. In my answer, I
will use the corrected private addresses.
Now, on to your problem:
I think that you misunderstand the meaning of "NAT". NAT stands for
"Network Address *TRANSLATION*". Translation means that one side of the
router does not know that the IP addresses on the other side of the router
exist at all. Instead, the router pretends that all traffic on one side is
actually coming from itself, *translating* that traffic to pretend that it
comes from the IP address of the router.
In your case, your pfSense is pretending that all traffic from the LAN side
with IP addresses 192.168.2.x is actually just traffic from the pfSense's
WAN IP which is 192.168.1.2. Any request for 192.168.2.x that comes from a
device on your 192.168.1.x network will fail because it has no idea that
the 192.168.2.x network exists!
Here are three ways you could solve this problem, in order from easiest to
hardest:
- Tell your clients for your media server to connect to the pfSense's
address 192.168.1.2 on the forwarded port. The pfSense will then
transparently rewrite the traffic to the server on the LAN side.
- Set up a route in your OpenWRT router that says that the "next hop"
for the 192.168.2.x network is 192.168.1.2. In that case, you don't need
any NAT on the pfSense, only firewall rules.
- If you have another open port on your pfSense (or you can add
another), reverse the order of the devices and put your WiFi inside the
pfSense too. Then set up your OpenWRT device as an access point only and
use pfSense for the routing, DHCP, etc. Then again, all you need to do is
set up the appropriate firewall rules.
Personally, I prefer the third option. The reason is that right now, your
OpenWRT device is doing NAT between you and the Internet, so your pfSense
is doing "double NAT" - a.k.a NAT inside NAT. While this usually works,
it's poor network design and it can sometimes cause weird problems.
Moshe
--
Moshe Katz
-- mo...@ymkatz.net
-- +1(301)867-3732
On Sun, Aug 14, 2016 at 4:55 AM, Antonio wrote:
> Hello,
>
> you'll have to forgive my newbie question but that where we are start at
> some point. I'm really keen to understand more about networking hence my
> desire to learn through pfSense.
>
> This is my setup:
>
> OpenWRT Router on the ADSL which has the 195.160.1.0 network on the LAN
> side and a pfSense linked to the 195.160.1.2 address on the routers LAN
> (so connected to pfSense WAN side). On the LAN side of the pfSense, I
> have 195.160.2.0 network with 195.160.2.1 on the LAN side. I have a
> server on the LAN on pfSense which I want isolate from all the wireless
> traffic that is going on the 195.160.1.0 (lots of guest accounts). But I
> also have a multimedia client on the 195.160.1.0 network that I want to
> allow access to the media server (195.160.2.2:8096) on the 195.160.2.0
> network.
>
> I've set up a NAT port forward rule on pfSense like this:
>
> InterfaceProtocolSourceAdd.SourcePortDestAdd
> DestPortNATip NATport
>
> WAN TCP **
> 195.160.2.28096195.160.2.28096
>
>
> I allowed pfSense to create the firewall rule automatically so this
> should be fine?
>
>
> Why do i not see traffic from the media client being logged (basically,
> the client does appear to be routed to the server through between the
> two subnets) but I do see traffic from the media client on the
> 195.160.1.0 being logged to the whole 195.160.1.0 network (I see UDP
> traffic from 195.160.1.4 to 195.160.1.255 being logged for netbios on
> 138) as blocked traffic. When I try to ping the pfSense WAN port on
> 195.160.1.2, it does get logged on pfSense but when I try to ping the
> LAN side of the pFSense from the WAN side, nothing gets logged. HAs this
> got to do with the default rules set up during setting up the WAN
> interface on PfSense:
>
> a) Blocks traffic from IP addresses that are reserved for private
> networks per RFC 1918 (10/8, 172.16/12, 192.168/16) and unique local
> addresses per RFC 4193 (fc00::/7) as well as loopback addresses (127/8).
> This option should generally be turned on, unless this network interface
> resides in such a private address space, too.
>
> b) Blocks traffic from reserved IP addresses (but not RFC 1918) or not
> yet assigned by IANA. Bogons are prefixes that should never appear in
> the Internet routing table, and so should not appear as the source
> address in any packets received.Note: The update frequency can be
> changed under System->Advanced Firewall/NAT settings.
>
> I have them both ticked but I thought the NAT rule would take precedence?
>
> Thanks
>
> geotux
>
>
> _