12-22-2011 07:20 PM
We have two ISP's. The intent is for one of them (T1-ISP) to be used exclusively for VoIP. The other (WISP) for all other traffic. In addition we have one VPN between two offices, nothing fancy just want to be able to access each other's computers and back-up DNS and AD server. Both sides have SSG-5’s. We are using MIP on both interfaces (eth 0/0 and eth 0/6) in the main office.
The SIP traffic is easy to identify. We have two servers which are dedicated to VoIP so all of their traffic can be routed to the T1-ISP by using their IP addresses as the source.
This sounds like simple Source Routing for the two VoIP servers and then letting all other traffic default to the WISP through the default destination 0.0.0.0 route which points to the WISP. I should be so lucky.
The issue I’m having is that Source Translation (MIP mapping) does not occur on the outbound packets through Source Routing, so the receiving end of a call is replying to the wrong IP (192.168.0.25 our private address behind the firewall rather than 38.119.x.25 our public IP address). So you get a one-sided phone connection.
I’ve set up Policy Based Routing and have been able to get it to work. But now one side of the VPN between the two offices is still somehow being routed through the T1-ISP even though I set up the VPN from scratch with the new WISP’s IP addresses. What happens is that a download from the main office to the remote office runs at T1 speed rather than the 4Mbps+ that it should be going at. However when I upload a file from the remote office to the main office it DOES run at the 4Mbps+ speed, through the WISP.
So I have three questions:
- Has anyone else run into this issue.
- What can be done so that Source Routing will map the IP addresses properly (Based on the MIP for the interface it is actually going through)
- Or what can be done with the VPN to get it to go through the WISP line. (I have a PBR action set to direct it through the tunnel but it somehow still gets routed through the T1 gateway.
Before I start sending thousands of lines of configs and debug logs I’m hoping that someone else might have run into this and found a solution.
12-23-2011 02:46 AM
Yes I believe I have had a similar issue in the past. It was with a very similar setup. Unfortunatly I never got the issue fixed and now no longer work at that company with that setup.
I'll see if I can dig up some more info as it was a while ago now. Sorry for no real useful info...
12-27-2011 02:28 AM
This might not be massively useful (as in you may have already done this) but have you tried a debug flow basic, after setting the flow filters to capture the VPN traffic that is being sent down the wrong path?
It should tell you why traffic is being processed the way it is.
There's quite a handy guide here:-
Also, you could setup seperate vrs, one for VoIP traffic and one for all other traffic. You could separate out your VoIP stuff onto a different VLAN on your switches (which is best practice anyway, so you can apply different QoS profiles to it through your LAN) and then have seperate Virtual Routers on your Netscreen for the two networks.
That would certainly keep things separate - you can even have a high metric failover for the data traffic into the voice VR if the connection to your data ISP fails.
Hope that helps/gives you a few ideas to think about!