Outbound NAT Issue
-
I have pfsense on a VM with two dedicated NICs for the VM. One NIC goes to the internet and the other goes through a passive filter to a Cisco 4506 which then leads to the rest of our internal network. We originally had an ASA5516 which died and we borrowed an older ASA from the regional education center until I get this pfsense working correctly. With the ASA in place everything works, but slow because the one we borrowed is 100M ports not 1G ports. The port on the 4506 is switchport access vlan 811, but if I program the NIC on the hypervisor as anything other than untagged then I completely lose connectivity with the rest of the network. If it is untagged then I can ping the pfsense from the 4506, but not from my desktop. I can open the web gui from my desktop and that works fine. I can ping any endpoint inside the network or outside from the pfsense, but devices inside can not access the internet or do a traceroute to or beyond the pfsense. I can access devices behind the pfsense that I have configured port forwarding for. I have RFC1918 addresses as my internal routes, outbound NAT and firewall rules. I switched to manual outbound NAT because the automatic was not working either. I've been working on this thing for days now and I just can't see what I'm missing. Any help would be greatly appreciated.
-
A Cisco access port is an untagged port. It needs to be talking to an untagged port. Not quite sure why you would be expecting anything else.
I would suggest dealing with one layer at a time and working up.
VLAN 811 on your network is something. What is it?
What address are you giving pfSense there?
What pfSense interface name are you assigning to that?
What firewall rules are on that interface?
I assume you are using a test network for this and everything behind the firewall on VLAN 811 is a test device.
All manual outbound NAT does is say "If I have matching traffic (which generally matches on the the source network) already going out this interface, apply this NAT to the source address/port on its way out."
If you are not doing anything special, I would re-enable automatic outbound NAT. You should see the test device network listed as a source there and WAN Address listed as the translation address. There should be two rules: One for source port 500 for IPsec from inside your network to the outside (which you probably do not need but will not hurt) and one for everything else.
-
@derelict said in Outbound NAT Issue:
A Cisco access port is an untagged port. It needs to be talking to an untagged port. Not quite sure why you would be expecting anything else.
I would suggest dealing with one layer at a time and working up.
VLAN 811 on your network is something. What is it?
What address are you giving pfSense there?
What pfSense interface name are you assigning to that?
What firewall rules are on that interface?
I assume you are using a test network for this and everything behind the firewall on VLAN 811 is a test device.
All manual outbound NAT does is say "If I have matching traffic (which generally matches on the the source network) already going out this interface, apply this NAT to the source address/port on its way out."
If you are not doing anything special, I would re-enable automatic outbound NAT. You should see the test device network listed as a source there and WAN Address listed as the translation address. There should be two rules: One for source port 500 for IPsec from inside your network to the outside (which you probably do not need but will not hurt) and one for everything else.VLAN 811 just has the two devices with the passive filter between. pfsense 192.168.200.1/24 and the Cisco 192.168.200.2/24
On the outside with have a /28 block of IP addresses.
WAN interface hn0
LAN interface hn1I re-enabled the automatic NAT and now I have:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 127.0.0.0/8 ::1/128 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 192.168.200.0/24 192.168.51.0/24 192.168.51.0/24 192.168.50.0/24 * * 500 WAN address * Auto created rule for ISAKMP
WAN 127.0.0.0/8 ::1/128 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 192.168.200.0/24 192.168.51.0/24 192.168.51.0/24 192.168.50.0/24 * * * WAN address * Auto created ruleMy manual NAT rules were almost identical except I had no IPv6 and I just had the RFC1918 addresses and the localhost address.
I tried firewall rules for the RFC1918 addresses, but I am just using the default rules allow everything from inside to outside.
I have 3 static routes:
Network Gateway Interface Description Actions
10.0.0.0/8 LANGW - 192.168.200.2 LAN
172.16.0.0/12 LANGW - 192.168.200.2 LAN
192.168.0.0/16 LANGW - 192.168.200.2 LANWhen I go look at the active routes I see:
Destination Gateway Flags Use Mtu Netif Expire
default x.x.x.238 UGS 92428 1500 hn0
8.8.4.4 x.x.x.238 UGHS 607 1500 hn0
8.8.8.8 x.x.x.238 UGHS 286 1500 hn0
10.0.0.0/8 192.168.200.2 UGS 15848 1500 hn1
10.0.4.19 x.x.x.238 UGHS 605 1500 hn0
x.x.x.224/28 link#5 U 31950 1500 hn0
x.x.x.225 link#5 UHS 0 16384 lo0
x.x.x.226 link#5 UHS 0 16384 lo0
x.x.x.227 link#5 UHS 0 16384 lo0
x.x.x.228 link#5 UHS 0 16384 lo0
x.x.x.229 link#5 UHS 0 16384 lo0
x.x.x.230 link#5 UHS 0 16384 lo0
x.x.x.231 link#5 UHS 0 16384 lo0
x.x.x.232 link#5 UHS 0 16384 lo0
x.x.x.233 link#5 UHS 0 16384 lo0
x.x.x.234 link#5 UHS 0 16384 lo0
x.x.x.235 link#5 UHS 0 16384 lo0
x.x.x.236 link#5 UHS 0 16384 lo0
x.x.x.237 link#5 UHS 0 16384 lo0
127.0.0.1 link#2 UH 506 16384 lo0
172.16.0.0/12 192.168.200.2 UGS 0 1500 hn1
192.168.0.0/16 192.168.200.2 UGS 659 1500 hn1
192.168.50.0/24 192.168.50.2 UGS 0 1500 ovpns1
192.168.50.1 link#7 UHS 0 16384 lo0
192.168.50.2 link#7 UH 0 1500 ovpns1
192.168.200.0/24 link#6 U 3125576 1500 hn1
192.168.200.1 link#6 UHS 0 16384 lo0I redacted the list (public addresses are as I said a x.x.x.224/28 and the gateway is x.x.x.238), but the one that really stands out to me is my internal domain controller/DNS server has the public gateway. The next hop from the pfsense to get to that server would be the 4506 and not the public gateway.
-
Well, problem solved.
I needed a floating rule for the LAN interface on direction in that allowed everything and now I can ping the pfsense and beyond it and all online content is accessible.
-
You should not need any floating rules.
You do need rules on LAN that pass all of the traffic coming from the downstream router. It looks like you have that as all of RFC1918. That might or might not be a problem as you add VPN connections.
I would move them from floating to the LAN interface tab. It's much more straightforward.