IPSEC Route all but local traffic
-
I feel like this is an IPSEC issue for when I tear down the tunnels im able to access the DMZ hosts via LAN
-
Yeah that's going to be tricky. The destination address on your other VLAN is included in 0.0.0.0/0 so the reply traffic is getting sucked into the traffic selector.
You could policy route the other VLAN on interface that is the Local IPsec interface (bypassing the traffic selector) but that would involve a gateway to route to that likely doesn't exist.
You might be able to outbound NAT the traffic out of the local interface so replies are same-subnet, but that will probably only work if the IPsec Local network is actually the "lan" meaning the second interface in the system (wan is first) since that is the only interface for which IPsec is deliberately bypassed. (enumerated in Status > Interfaces).
This is all a lot easier with OpenVPN.
-
going that way now.
-
followed https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site but now I have no access to to the DMZ network and the DMZ network can not ping to the internet.
bummer
-
Then you did it wrong. :P
That document doesn't cover everything necessary to policy route internet traffic out the VPN, assigned interfaces, etc.
You at least need to:
Assign an interface
Make sure all the rules are where they need to be
There was this thread a while ago. Most of what you need should be covered. You will probably need less NAT since you're dealing with routable addresses.https://forum.pfsense.org/index.php?topic=82732.msg453269#msg453269
-
thanks. That helped a bit.
I have outbound internet working as expected but inbound.. the nat is not working.
from a host on the DMZ, I go to whats my IP and the traffic goes across the open VPN tunnel and out the public ip it's 1:1 tied to. change the 1:1 relation to another public IP sees this updated via a browser refresh.
can ping out as well.. no issues.
internal hosts on the LAN, local to the DMZ, can access the servers locally. so im close!
-
Not sure what to have you check there.
Be sure the rules on the OpenVPN tab on the DMZ side of the tunnel do not match the inbound traffic. If they match the OpenVPN (interface group) tab it won't work.
They have to match the rules on the assigned interface to get the benefit of pf's reply-to functionality or the replies to the inbound connection will follow the routing table (likely be forwarded out WAN) instead of back through OpenVPN. This is a main piece of the puzzle that you cannot do using IPsec.
-
haha.. well not I managed to go far back and nothing works again :(
on both boxes, I have a PIA interface created. this interface shows up after the openVPN tunnel comes up.
on PFA - this is the router in the sky terminating all my Public IP's - I have NTAs to forward 1.1.1.1:3389 to 10.253.253.1
on PFA - my openVPN config has Tunnel Network = 10.200.200.0/24 and IPv4 remote networks as 10.201.201.0/24
on PFA - I have my openVPN firewall rule to allow 10.200.200.0/24. <– --> 10.201.201.0/24. bi-directional
on PFA - I have my PIA rules the same as openVPNon PFB - this is the router which terminates the VLN's and the 10.253.253.1 subnet.. I have a firewall rule setting my next hop for all 0.0.0.0/0 traffic to the openVPN interface
on PFB - my openVPN config has Tunnel Network = 10.201.201.0/24 and IPv4 remote networks as 10.200.200.0/24
on PFA - I have my openVPN firewall rule to allow 10.200.200.0/24. <-- --> 10.201.201.0/24. bi-directional
on PFA - I have my PIA rules the same as openVPN -
ok.. outbound is working again. HAHA. sorry. this is hard to follow im sure. really thank you for your efforts thus far!!
on PFA - this is the router in the sky terminating all my Public IP's - I have NTAs to forward 1.1.1.1:3389 to 10.253.253.1
on PFA - my openVPN config has Tunnel Network = 10.200.200.0/24 and IPv4 remote networks as 10.201.201.0/24
on PFA - I have my openVPN firewall rule to allow 10.200.200.0/24. <– --> 10.201.201.0/24. bi-directional
on PFA - I have my PIA rules the same as openVPN + Source: 10.253.253.0/24 Dest: anyon PFB - this is the router which terminates the VLN's and the 10.253.253.1 subnet.. I have a firewall rule setting my next hop for all 0.0.0.0/0 traffic to the openVPN interface
on PFB - my openVPN config has Tunnel Network = 10.201.201.0/24 and IPv4 remote networks as 10.200.200.0/24
on PFA - I have my openVPN firewall rule to allow 10.200.200.0/24. <-- --> 10.201.201.0/24. bi-directional
on PFA - I have my PIA rules the same as openVPN -
If 10.253.253.1 is on the other side of the tunnel then it needs to be a remote network on PFA for starters.
What does PIA have to do with anything? First time you have mentioned another OpenVPN client.
I don't have the time to draw your diagram for you right now.
-
not asking for you for drawl anything and again i thank you for your time this far!!
the PIA is nothing more than what i changed the openVPN adaptors to. its a name reference only
-
per your suggestion
on PFA I changed the openVPN config as follows
Tunnel network: 10.200.200.0/24
Remote networks: 10.254.254.0/24on PFB I changed the openVPN config as follows
Tunnel network: 10.200.200.0/24
Remote networks: 10.253.253.0/24when openVPN comes up they have the following iP
PFA 10.200.200.1/24
PFB 10.200.200.2/24on the PIA rule set (again this is the openVPN interface name ONLY) I have allow bidirectional 10.200.200.0/24
on PFA I have a 1:1 nat from public IP 1.1.1.1 to 10.253.253.1
on PFB I have a firewall rule at the top of DMZ network (10.253.253.0./24) to set next hop to be PIA interface.
doing a trace route from 10.253.253.1 to 8.8.8.8 shows the traffic hitting 10.200.200.1 first (PFa's openVPN interface).
PFA has a LAN IP of 10.254.254.254/24
PFB has a LAN IP of 10.253.253.254/24NAT rules on PFB are set to manual
-
got it fixed. missing nat rule on PFA from internet to 10.253.253.0/24 network
