Our ISP originally assigned us a static IP on a /24, we asked for additional IP’s and rather than assigning us a /29 or /28 they just said here is 10 IP’s in the same subnet as your 1 static, so we have x.x.x.68 and x.x.x.80-89.
We had the router configured to use .68 as it’s default IP for all outgoing traffic and set up NAT rules that things going to .81 would go to our Exchange server and .82 to our terminal server. Everything was fine for the past few months. We just put in a VOIP system and we thought we would be proactive and set it up to use .83, however we can’t figure out where to set it up to have all traffic from the VOIP server to always go out .83 and everything else to keep working on .68. Since our server connects to the SIP proxy it has to go on .83 or the provider blocks us. We attempted to make some changes last night and our router became possessed, static IP’s kept falling out of the config, our LAN subnet, a /23 would start multiplying on to other interfaces and if we opened quickset it had the .83 address listed as the WAN address and the .68 listed as the LAN address. We kept changing things back and a few seconds later something else would disappear or multiply. We finally reset to factory and I restored a config file (not a backup) from the 11th of this month and it seemed back to normal until we tried re-adding the .83 address and then all hell broke loose again. After 3 hours of frustration we finally got it stable and then at 3am this morning it blew up on it’s own and we were down until one of us could get here. We ended up switching back to what has been working for the past few weeks, we put the .83 IP on a different router and plugged the VOIP server into it and now we are back and stable.
Long story short, I need to know how to configure multiple WAN IP’s from the same /24 and have the router be able to send the packets out on different WAN ip’s depending on where they originate from within the LAN. It’s the same connection, so there is no need to load balance, all of the articles I’ve found similar to my issue is they had 2 or more WAN connections that shared a common gateway, my issue is similar except it’s only 1 WAN connection, just multiple IP’s and they all share the common gateway. I’ve tried creating mangle rules with routing marks and could not get it working.
Reading the above I am expecting that you sometimes enter data on the Quick Set screen and click the OK or APPLY button.
NEVER DO THAT. NEVER use Quick Set after initial configuration because it will lead to situations like you describe!
Don’t even look at that screen. It’s info is often wrong after you have made a complicated config.
Otherwise, it is impossible to describe in detail how to achieve what you want because you do not describe your internal network.
I think you are using NAT. If so, make sure you do not use MASQUERADE but use SRC-NAT. There you can specify the IP to use.
You will need a separate rule for your VoIP system and the other systems with different to-address.
I did make a change once last night with it, but it was long after it started freaking out. I only use quickset (after the initial setup) to see what it shows for dynamic IP addresses and sometimes just to see how far out of whack it is, I would normally not click apply. Last night we had grasped at every straw we could think of and I used it to see if it would stabilize things, and it didn’t, but then nothing did until we wiped and dumped the config back in.
As a side question, I have a script that does an export of the full config and emails it to me from our routers, we have 8 remote and our main one, and I used the last config that was emailed to rebuild it last night. Do you know if it’s maybe not “full”, because we still have strange after effects. I had 2 NAT rules one for each of the extra static IP’s to forward to exchange and terminal server. The terminal server one worked fine, the exchange one didn’t. So for now I have it moved back to the .68 address and it seems to be working there. The rules are exactly the same as each other except one references .81 and the other .82, different ports, and different dst-nat IP’s, but no other settings. One continues to work fine and the other doesn’t. I have to keep at least one of them on a different address since they both require port 443 to be available to them and it has to know which one you mean to go to in order for it to forward correctly.
Thanks,
Also, it’s a CCR1009-7G-1C-1S+, our remote sites are using the 5 port HEX’s.
Yes I think that should work. I am never sure if matching a src-nat rule terminates rule processing or not. If not, the rules would have to be reversed.
Also, remember that any nat rule change only affects NEW connections, so you need to reboot the router or the VoIP system after changing that.
Nope, it didn’t work. Tried both directions, no internet at all, turned masquerade back on and put it before and after and still no go. Once I disabled the rules everything went back to working…
I had our SIP provider just switch their settings to match our main IP and everything is working. Would still like to know how to make this work, but I guess I can tackle that another day.
Don’t forget to add the new IP to the interface and add a DSTNAT rule for the inbound traffic to make it to your SIP broker. The following should work fine.
Unfortunately there appears to be no way to really clear the NAT table. Several reports exist about trouble with NAT when using dynamic
addresses, for example.
It appears to especially affect VoIP. Probably there is a problem with clearing the state of the SIP helper in NAT.
I’ll try again tonight, but I lost internet access as soon as I added the src-nat commands and removed the masquerade. I am assuming I don’t want masquerade if I am manually src-nating everything, correct?
Masquerade as the last rule as a catch-all is fine. Just make sure its the last rule. That said if the first two rules are correctly defined for the network you shouldn’t need it. The reason you want to remove it from the config is with multiple IP addresses its unpredictable what IP it will use for outbound traffic.
Verify that the SRCNAT rules are covering the subnet you are originating from. Is the outbound interface correct? Those are about the only two things that would be stopping this from working correctly.
Can you paste the output of the commands listed below. Remember to encase them in code blocks for proper formatting in the forum:
Weird. I know on my post I don’t show having .87 on my address list it’s because I removed it earlier and just didn’t change the disabled srcnat.
I just put .84 on and changed the srcnat to point at it and it’s working…
So I’ll just go stick my head back in the ground… Thanks for all the tips, I’m sure it helped, but still confused why it didn’t work last night.
Could be an order of operations error by not having the more specific network above the less specific in the NAT rules. OSPF shouldn’t have any affect on SRCNAT working or not working in this case.