Really need 3G help

[dhopper82]

I am working on an issue with 3G where the connection drops periodically over an IPSEC tunnel. The signal in the area is strong but when this happens the ip address of the 3G card drops and has to be renegotiated. Verizon, the provider says that a possibility could be that the verizon network is seeing our private network (10.X.X.X) and dropping our connection. I don't know how accurate this is because we are not doing any split tunneling or NAT anywhere. However, I am willing to try anything to resolve this. I was told that there may be stateful commands to put in the router to make sure Verizon doesn't see the private network. Any Ideas as to what these might be?

Here are my cellular interface commands...

interface Cellular0/2/0

ip address negotiated

ip access-group inbound in

ip access-group outbound out

ip virtual-reassembly

encapsulation ppp

dialer in-band

dialer idle-timeout 100000 either

dialer string cdma

dialer-group 1

async mode interactive

ppp authentication chap callin

ppp chap hostname 1112223333@vzw3g.com

ppp chap password 7 4682jj

crypto map ipsectunnel

!

Again, any help would be greatly appreciated.

[Giuseppe Larosa]

Hello Dennis,

you have applied a crypto map to the interface so your traffic shouldn't be seen by the provider.

second note:

this is a DDR configuration I see you have tried to increase the idle-timeout on your side however, also the other side can close the PPP session if its own idle timer expires.

And you don't know what is interesting traffic for the provider.

to check this you can try to add a RTR or ip sla object that tries to ping the other side without being considered interesting by the ACL that decides what goes encrypted.

The idea is to have a clear text ip flow travelling on the link.

Hope to help

Giuseppe

[dhopper82]

Thanks Giuseppe,

On the other side we have an ASA that pings the line every 5 seconds. I don't think it's a timeout issue because this line has dropped several times when users are doing work over it. It appears to be totally random.

I am pretty certain what's happening is the provider is knocking us off for whatever reason. I've just got to figure out if there is a way to remedy the situation from my side.

Thanks,

Dennis

[Giuseppe Larosa]

Hello Dennis,

I see you are already trying to keep the link alive.

I agree that the provider may have some issue: if the drops were regular it could be the result of some policy.

Being random it can be a problem on the provider network.

Hope to help

Giuseppe

[dhopper82]

The provider mentioned possibly setting up stateful inspection on the Cellular interface. Are you (or is anyone)familiar with the commands needed to do this?

[dhopper82]

Here's a thought. Is there a particular IPSec encryption that is known to work well with 3G?

[dhopper82]

Also, I have set up a router at my desk that has not gone down. The only difference between it and the other ones I have out in the field is that I took the IP virtual-reassembly out. In my eyes there should only be the IP address negotiated. Is there any possibility to this line of thought?

[billy_maclin]

I've got the same issue here. The cell interface will stay up indefinitely and retain its negotiatied IP address when using NAT and hitting the Internet directly, but if using VPN and a crypto map on the cell interface, the cell (and subsequently the VPN) connection drops after only a couple of minutes. Since you're not applying NAT or IOS firewall on the interface, remove virtual reassembly, as it's not needed and this should take care of the problem.

Just remember that if you configure nat on an interface and then remove it later, virtual reassembly will have reappeared.

[dhopper82]

Thanks Billy,

I was noticing that virtual reassembly creates a virtual interface on the router. It is possible that some traffic is going out showing a private IP because of the interface and therefore when the provider see's it they drop the connection. This is a theory right now but last night the router at my desk dropped once in a 15 hour timeframe. Man I hope this works!

[dhopper82]

I am going to test this today on a production box. Worst case scenario is that the drops will still be there. I will post in this ticket if it works or not.

[dhopper82]

This did not appear to work. My IPSEC tunnel dropped 27 times despite having great reception! Any other ideas? How about putting a second antenna on the 3G card? Again, any help would be appreciated!

[patrickvanham]

While it adds an extra header, try setting up the internal interface in a vrf, a tunnel interface (GRE) in the same vrf with the crypto map applied and set the tunnel to peer with the remote end. Only leave the 3G interface in the global routing table. If the drops still occur the provider cannot say the see internal addresses.

It should look something like below:

3G interface global routing table

|

Tunnel (GRE) with cryptomap vrf Something

|

Internal interface vrf Something

[dhopper82]

Thanks Patrick but the ASA's we're running our tunnels over cannot support GRE to the best of my knowledge. If there is a way to do it through ASA I would definately be interested in knowing though.

[dhopper82]

Here's the messages I'm getting on my routers...

Jul 23 2009 03:36:25.781 CDT: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed s

tate to down

Jul 23 2009 03:40:05.276 CDT: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed s

tate to up

Jul 23 2009 03:40:09.192 CDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC p

acket has invalid spi for destaddr=123.321.123, prot=50, spi=0xFFDF1999(42928

11161), srcaddr=68.1.1.1

Jul 23 2009 03:40:15.056 CDT: %CRYPTO-4-IKMP_NO_SA: IKE message from 111.123.111 has no SA and is not an initialization offer

[rtjensen4]

I had a similar issue, and it was because VZN was seeing my internal traffic. I found a great troubleshooting doc on Cisco's website, i can't find the link right now but I will attach the PDF. The part i found useful was way at the end in the troubleshooting section.

In my case, this link is for a backup ONLY and I didnt want users at the remote branch to access the internet through it, bypassing our corporate security setup... So I didn't do any catch-all NAT and whenever the router tried to get to its TACACS server across the Cell interface, or it tried to start up the BGP session, it would get torn down. This router had some "Extra" config on it.

Once I put the strangle-hold on the router as to what could and could not go out the cellular interface, it has been rock solid and speeds have increased for me. Good luck.