03-03-2022 03:15 AM
Hi,
I am having some trouble successfully creating a NAT/PBF combination. Long story short...:
We have an office with two WAN switches that have IP addresses in the same range as that office LAN WiFi IP range. Thus if anyone in the office or on their VPN tries to SSH to these switches the core switch routes it back to the LAN as that is where the IP range of the WiFi lives. I am trying to implement NAT/PBF go get SSH from the LAN to these WAN switches to work.
At first I thought I could create NAT/PBF rules to get this working if the LAN machine SSH to 2.2.2.2 but it isn't. Please see attached screenshots. I created a NAT rule with the Original packet source address as the LAN machine IP, destination address as 2.2.2.2 and the Translated packet as the WAN switch IP address. I then created a PBF rule with the Source as the LAN machine IP Destination address as the WAN switch IP and the Forwarding Egress interface as the interface connected to the WAN switch.
When I try to SSH using 2.2.2.2 I see the firewall logs as destination IP address 2.2.2.2 which is of course incomplete. Does the PBR take place before the NAT? If so I am not too sure how to get this to work. Many thanks in advance!
03-03-2022 03:41 AM
I forgot to mention that originally I put the NAT Translated Packet as Static IP and specified the WAN switch IP but that didn't work either.
03-04-2022 06:30 AM
Just going to back this up a minute.
@MichaelBorg wrote:We have an office with two WAN switches that have IP addresses in the same range as that office LAN WiFi IP range. Thus if anyone in the office or on their VPN tries to SSH to these switches the core switch routes it back to the LAN as that is where the IP range of the WiFi lives. I am trying to implement NAT/PBF go get SSH from the LAN to these WAN switches to work.
So if I understand this correctly you have two WAN switches that have management IPs in your internal LAN, and when someone tries to connect to them you are routing them through your existing route table to your internal core switches that don't actually have a route to the WAN internal IPs?
If that's correct, why are you using that IP range in two different spots without having a route between each other? Seems like a really simple change would be to put the management IPs of the WAN switches on a different subnet, or better actually route them on the internal network so that they're reachable correctly.
If you want a really simple way to fix this, just make a dedicated route statement for that IP in your route table out the proper interface and exclude them in your DHCP pool. The more specific route for these two IPs will have them go to the proper space without the use of NAT and PBF for simply two IPs.
03-15-2022 06:03 AM
Hi BPry,
Apologies for the very late reply.
Yes you are correct in everything you just stated. Your suggestion would be the better way I agree but I wanted to avoid making infrastructure changes that could affect the rest of the production network. If my original NAT/PBF idea won't work then I'll have to go with your suggestion.
03-15-2022 02:34 PM
Hi again BPry,
Thanks again for your reply to this. I've had another look into this today and it will be difficult to route a new management IP from the wan switches. I can't exclude the IPs from the WLC either because it's a Cisco WLC which isn't a true DHCP server and as far as I can see, can't exclude addresses.
It's there no way to configure this NAT I originally wanted? Thanks again in advance.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
