Really need 3G help

Unanswered Question
Jul 21st, 2009

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 [email protected]

ppp chap password 7 4682jj

crypto map ipsectunnel


Again, any help would be greatly appreciated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Tue, 07/21/2009 - 11:19

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


dhopper82 Tue, 07/21/2009 - 11:43

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.



Giuseppe Larosa Tue, 07/21/2009 - 12:05

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


dhopper82 Tue, 07/21/2009 - 12:41

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 Tue, 07/21/2009 - 12:53

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

dhopper82 Tue, 07/21/2009 - 13:00

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 Tue, 07/21/2009 - 14:08

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 Wed, 07/22/2009 - 05:14

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 Wed, 07/22/2009 - 06:52

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 Thu, 07/23/2009 - 05:12

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 Thu, 07/23/2009 - 05:59

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 Thu, 07/23/2009 - 06:14

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 Thu, 07/23/2009 - 06:28

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=

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 Fri, 07/24/2009 - 07:38

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.

billy_maclin Fri, 07/24/2009 - 09:37

Sorry that wasn't any help for you, but now that I've removed ip virtual-reassembly from all interfaces, the connection has been rock solid, even with less than optimal signal. I've only got 2-3 bars at my desk. I'm taking it home with me this weekend to see how it performs in the sticks.

I'm strictly using VPN, so there's no way for the carrier to see any RFC 1918 addresses; only the ISAKMP and IPSEC between the endpoints of the tunnel are hitting the carrier network.

dhopper82 Wed, 07/29/2009 - 07:27

I've tried all these solutions and nothing is working. I'm beginning to be convinced that IPSEC and Vorizen 3G aren't that compatable. Does anybody have a good article on setting up GRE? I have a 2811 with advanced security I can set up here since I've only got 10 sites connected 3G.

dhopper82 Thu, 08/06/2009 - 12:32

Just an update to this situation for anyone who may be experiencing the same issues. I talked with the Verizon network and they said that the line is experiencing an IP Source Violation. I am going to be setting up a monitor with them tonight to see if the IP in issue will show itself. If I get a fix on this I will post it.


This Discussion