SOLVED: Help replacing Cisco ASA - combined ip forwarding and nat modes?

Product Discussion Peplink Balance
1

For background, the nonprofit organization I work for supports multiple public library systems with multiple branches per system. At the moment, it is about 26 sites that we support. Most of these sites are fortunate to be able to connect directly to a state wide library WAN network. A notable few exceptions are connected via a commercial ISP.

Many many years ago, every branch was allocated IPv4 network address space in the state wide library WAN network. Each branch had an ISDN modem that would connect a 56K channel. All the computers in the branches had public IP addresses, and their network size was determined by their need at the time. They had Sonicwall firewalls.

When I was hired, there was a project in place to replace all the Sonicwall firewalls with Cisco Pix firewalls, and I was able to assist in that project. As part of that project, we reconfigured every network with multiple VLANs, so there was now a WAN (outside), Staff (inside), Patron, and DMZ network. Staff and Patron were RFC1918 addresses in the 192.168 range. DMZ was the former public address space.

Over time, and many upgrades, we now have ASA 5506 firewalls acting as firewall, router, and nat device for each branch. Most of the branches are fortunate to have a high quality link into the state wide library WAN, typically over fiber. Over time, most of the sites have effectively stopped using their DMZ addresses, as they stopped having their own servers, and typically 3-5 IPs are used solely for NAT purposes. We have also added the obligatory BYOD network everyone seems to need these days.

I am in the process of replacing the ASA firewalls with Balance 20x model (and in one case, a Balance 310 Fiber 5G).

The problem I am running into is the locations where they still use their public IPs as a DMZ with public facing services.

So picture this example (using TEST-NET-x IP ranges as examples):
WAN network: 192.0.2.248/30

  • interface IP: 192.0.2.250 # my WAN IP
  • gateway IP: 192.0.2.249 # ISPs L3 switch

DMZ network: 198.51.100.128/25

  • interface ip: 198.51.100.129

Staff network: 10.32.1.0/24

  • interfaece ip: 10.32.1.1
  • public NAT address: 198.51.100.150

Patron network: 10.32.2.0/24

  • interface ip: 10.32.2.1
  • public NAT address: 198.51.100.151

BYOD network: 10.132.0.0/16

  • interface ip: 10.132.0.1
  • dhcp pool: 10.132.0.2 - 10.132.255.254 # to support a ton of random BYO users
  • public NAT address: 198.51.100.254

This is an oversimplification. However, there is equipment in the 198.51.100.128/25 network that cannot easily be moved to a new IP.

I have tried everything I can think of to set the primary WAN interface to IP Forwarding mode, creating a VLAN to be called DMZ with the 198.51.100.128/25 network, using the .129 IP for itself. Then set up VLANs for Staff, Patron, and BYOD, and try to have them NAT to the appropriate public IP in the DMZ.

Things I have tried:

  • Primary WAN as 192.0.2.250, in IP Forwarding mode (aka routed mode)
  • Additional WAN in NAT mode: either a USB Ethernet adapter, or more recently VLAN as WAN, with a cable connecting back to a port in access mode in the DMZ VLAN,

For the life of me, I am just unable to produce a similarly functional configuration as what the single Cisco ASA does. I am positive it is my own lack of understanding to blame here, hence seeking advice from the peplink community at large.

The only thing I have managed to get to successfully work for me is to use 2 peplink devices, one in IP Forwarding mode, the other in NAT mode, back to back. Obviously, this seems wasteful, and is hard to explain to management. “well, you see, the peplink is super awesome, but we have to buy 2 of the things to replace the thing”. That is simply not an argument I wish to try to justify.

I will admit that my comprehension of SNAT and DNAT etc isn’t the best, and I suspect that is a majorly contributing factor.

Any advice would be very welcome!

Thank you for your time and attention,
Jim

1 Like
2

Hello @Jim_Gifford,
Where in the world are you based? This is something that an experienced Peplink Partner & Peplink Engineer would be solving for you.

If you want to let us know what country you are based in, we can point you to some experienced Peplink Partners; several are active here in the Forum.

We use Peplink’s InControl2 to work with our customers to support, resolve, and maintain Peplink-based solutions remotely. Have you already provisioned InControl2 with the devices?

Reading through your text, it may be easier to solve with a network schematic. Do you have one handy?

Happy to Help,
Marcus :slight_smile:

3

Thank you Marcus.

I did not even think to run this past my Peplink Partner before posting here. I will do that.

Yes, I am using ic2 to manage the devices.

I do not have a current network schematic. It is easy enough to read the config files and visualize how things are connected, which isn’t horribly complex. perhaps over complicated, but not very complex.

I appreciate the rapid response,
Jim

1 Like
4

I’ll work offline with Jim , and report back here.

2 Likes
5

So I have been working on this off and on for over 18 months. Nothing I tried would work. The last time I tested was probably around October.

Since October, 8.4.0 was deployed to all my devices. I never conducted a test with 8.4.0, so I cannot say if that changed things in a way that helped solve this for me or not, because the solution I came up with was one I had NOT tried before.

Jonathan was good enough to open a support ticket with Peplink for me. Of course, I was unprepared, not having a device configured as a test case, so I quickly set up a test environment, and in the process of doing that, had an epiphany.

TLDR; My thinking was to have multiple private networks that NATted into the DMZ network (with DMZ being like a WAN for those networks), and having the DMZ network routed (IP Forwarding mode) to the actual WAN. That was incorrect thinking.

Solution: Set WAN to IP Forwarding mode. Configure DMZ network correctly. Add ONLY the public NAT addresses for the other networks to the WAN’s “Additional IPs” section. Configure outbound NAT to use those IPs for each of those networks. Enjoy.

Yes, it is pathetically easy, and obvious in hindsight. Testing shows that a DMZ address used as an Additional IP no longer will route into the DMZ, which matches my memory of how the ASA behaved, and matches any rational expectation.

I know in my earlier testing, I would put the entire DMZ into Additional IPs for the WAN, which obviously did not (and in retrospect should not ) work.

Thank you to everyone that helped me get past my mental block and resolve this issue. Special thanks to Jonathan and Peplink for their super fast response.

With this resolved, I will be busy the next few months with the final rollout.

Have a good day,
JIm

1 Like