Dual WAN & NAT – Setting Up Cisco RV325

cisconat;

I have a Cisco RV325 (Small Business Router), and two WAN ports with two different services.

WAN1: Comcast – Home Service (256Mbps Down, 30Mbps Up) – Single Dynamic IP
WAN2: Comcast – Business (100Mbps Down, 20Mbps Up) – 5 Block of Static IP's

I am using One to One NAT on several of the IP Addresses from WAN2

If I am not specifying NAT, I don't want to use WAN2, I want to stick with WAN1 for all other traffic. Where WAN2 is for my PBX, Mail Server, and other servers.

Here is my WAN Setting Table:

Here is my One to One NAT:

Here is my Dual WAN configuration, this seems to be the only way the NATed addresses work:

And here is my Bandwith Managment screen:

What is happening now, is that sometimes while I am in load balancing mode, my non-natted traffic starts going over WAN2, and I don't want that. While other times, it goes over WAN1.

How do I stop this from happening, forcing all non-natted traffic to go over WAN1? I have tried turning Smart Link Backup on, but then it shuts down all of my NAT's from using WAN2 all together.

Best Answer

With my testing, I found out that it does work, however not 100% stable. So what I did was got another router as a new gateway but same subnet. I then added that to my network switch, and it worked perfectly, with that new switch, I am running the NAT, and for the NATed computers, I have set the new subnet.

Related Solutions

pfSense – Multi-WAN Bridge, NAT, Load Balancing, and CARP

This could be cleared up quite nicely by using a one-to-one (or static) NAT. Your interfaces would be set up the same as they currently are, only difference is you wouldn't bridge the WAN/DMZ interfaces.

The only thing this will not accomplish is allowing you to speak from the LAN address space to your external address space. I assume the issue there is perhaps a DNS request is returning the external address? If that's the case then you could change your BIND config to include two different views - an internal and external - to provide different returns based on the source of the DNS request.

I believe the only other solution - to get everything that you're asking for here - is to have both ISPs assign you another block of addresses that you'd use on your DMZ interface.

As for the hardware failure bit, this should work fine as long as your interfaces are connected in the same L2 area as the fist firewall. It sounds like it's active/passive so this should be fine.

Cisco – QoS voice traffic on WAN of Cisco 1841

The short answer is no. Your queuing policy needs to be applied outbound at the point of bottleneck. In this case, the bottleneck is the WAN connection (20 Mbps) between the pfSense and the 1841. Thus, the proper location of your queuing policies are outbound on the LAN interface (a bit of a misnomer) of the pfSense and outbound on Fa0/01 of the 1841, which you have.

All that being said, your policy on the 1841 is flawed. In your example, you've reserved 1 Mbps of bandwidth for VoIP and applied the policy to a 100 Mbps interface. What happens when the PCs start pushing 70Mbps of traffic while trying to make a VoIP call? From a queuing standpoint on the 1841, the answer is nothing. There is only 70 Mbps of data flowing out Fa0/1. Therefore, there is always 1 Mbps available for VoIP. However, once this traffic reaches the pfSense, at least 50 Mbps of data and VoIP will be dropped. Your calls would be terrible at best.

Without getting into all of the details, and using your prior example, the policy should be something like this:

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145
!
policy-map PM-PRIORITISE-VOICE-child
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map Shape-20Mb-parent
 class class-default
  shape average 20000000
  service-policy PM-PRIORITISE-VOICE-child
!
interface FastEthernet0/1
 service-policy output Shape-20Mb-parent
!
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

This policy creates an artificial bandwidth limit on all traffic leaving the Fa0/1 on the 1841. Thus, the pfSense will never have the opportunity to drop traffic indiscriminately. Also, instead of the bandwidth command, the priority command should be used to limit latency and jitter. The tagging and the ACL change should be self-explanatory.

Related Topic