NAT issue w/2 LANs connected via T1
-
Hello, I've been trolling the NAT board here but can't seem to find a fix.
LAN1
192.168.33.1 = pfSense
192.168.33.2 = Cisco 1760 #1, eth0
192.168.44.1 = Cisco1760 #1, eth1LAN2
192.168.22.2 = Cisco 1760 #2, eth0
192.168.44.2 = Cisco1760 #2, eth1- I'm trying to send Internet traffic from both LANs out the pfSense router
- the link 192.168.44.1 to 192.168.44.2 is a T1
- the traffic is flowing between the LANs - there does seem to be a lag though, as if it trys a 'path1' then that fails/timeouts and 'path2' works
- running pfSense 2.0.1
- if I try a traceroute from the 192.168.22.x LAN it drops/dies at 192.168.44.1 - as if pfSense does not know how to send traffic back to the 192.168.22.x segment from the 192.168.33.x segment
- I'm fairly sure this a basic setup issue, just not familiar enough with pfSense for proper setup
-
So if I am to understand this correctly, you are wanting to somehow route on 2 separate interface on the same subnet? This is not possible. Those you are not really firewalling here are you?
Or perhaps you are not explaining the setup clearly enough.If it is a NAT issue, then since you have multiple networks, you are going to have to use manual outbound NAT and also rule(s) on the LAN interface to allow that traffic. The manual outbound NAT needs to be setup so that each subnet uses either a VIP or the WAN address.
You will also have to setup reverse routes in pfsense so it know how to route the returning traffic.
-
Hi everyone,
Thanks for the comments. I can accept that the source port is randomized on outgoing packets and the replies back have a src AND dest port of 5060 means that basic nat won't work. What I can't understand is that there is no rule I can put in place to forward the replies to my pabx. My port forward rule of dest port=5060 should forward all udp packets regardless of source port shouldn't it? The rule says src port * src addr * dest port 5060 forward to pabx. It seems to be ignored. Can someone explain to me why this isn't happening?
Regards,
Tony -
Hi everyone,
Thanks for the comments. I can accept that the source port is randomized on outgoing packets and the replies back have a src AND dest port of 5060 means that basic nat won't work. What I can't understand is that there is no rule I can put in place to forward the replies to my pabx. My port forward rule of dest port=5060 should forward all udp packets regardless of source port shouldn't it? The rule says src port * src addr * dest port 5060 forward to pabx. It seems to be ignored. Can someone explain to me why this isn't happening?
Regards,
TonyI think you posted to the wrong case.
-
To be more clear:
LAN1
192.168.33.1 = pfSense >> default gateway out to the Internet
192.168.33.2 = Cisco 1760 #1, eth0 >> catches all local traffic and either a) routes it to the remote site or b) sends it off to the default gateway
192.168.44.1 = Cisco1760 #1, eth1 -
Okay, so you just need a route in pfsense that states that anything going to 192.168.44.0/24 goes to the 192.168.33.2 gateway. Then you are going to need a rule that allows that traffic and a NAT rule to transform Internet destined traffic into a VIP or WAN address.
-
So if I setup manual NAT it should look like this - correct? Part of the noob-ness here is that I'm not sure if I need to route the 192.168.44.0/24 traffic with a NAT rule.
-
Here's what I have now, just added the last line '192.168.44.0/24 >>> 192.168.33.2'
-
Yes, you need to add one for the 192.168.44.0/24 and also 127.0.0.1/32 (so pfsense itself can use the internet for updates and some services). If you switch to auto, save and then switch back to manual, MAYBE the default rules will come back and you can just ADD the 192.168.44.0/24 on the chain. or perhaps not, in which case we can help you out with those.
-
Great, I can now traceroute from the far side to the local side and out pfSense. Thanks Podilarius!
Here's my setup, do you see any cleaning up that needs to be done (i.e. extra routes/rules/NAT not needed)?
-
On the wan rules you don't need the 192.168.22 or 44/24 listed there. according to the diagram, those networks should not be on that side of the FW. plus the wan rule to block private ips above ensures that it will be blocked anyway.