Heres a good one.. IPSec VPN question

In article , Richard Graves wrote: :Does anyone know if an IPSec VPN (between two PIX 501 over a T1) can stay :established if there is a continuous 400ms of latency on the line?

That's not a T1 latency, that's a satellite latency.

Normally, I would agree with you Walter. But this actually is a P2P T1 line. Its a link between two public sector office buildings in a major city in the north-eastern US. They do not regulate internet usage, so every Tom, Dork, and Harry is running peer-to-peer filesharing, streaming media, and who knows what else. To top it off, they will not let me help them implement QoS so that I can prioritize my traffic above the average web surfer...lol I love working for the government...lol

-Richard

|> That's not a T1 latency, that's a satellite latency.

|But this actually is a P2P T1 |line. Its a link between two public sector office buildings in a major city |in the north-eastern US.

You'll have to excuse us if we ask "Are you sure??" For example, do you measure low ms latency in the middle of the night when everyone's gone home?

| They do not regulate internet usage, so every Tom, |Dork, and Harry is running peer-to-peer filesharing, streaming media, and |who knows what else. To top it off, they will not let me help them |implement QoS

So it isn't that the T1 link -itself- is 400 ms latency, but rather that it is going through heavily used equipment? Is the T1 link itself loaded, or is it some loaded device between the IPSec endpoint and the routers, or is it the router?

If you were to have a cable run installed so that the PIX were directly connected (or via a lightly used switch) to the routers that are the T1 endpoints, then would that help?

A question: if the T1 is point to point between offices, then that would often be considered "secure enough" [depending, of course, on the sensitivity of the data going over the link -- but if you have notably sensitive data then the PIX isn't quite rated to be able to carry it under US and Canadian government classification regulations.] The PIX would introduce extra latency and potentially reduce throughput -- the

501's aren't quite rated to be able to handle a full duplex T1 (and they won't at that latency!).

With what you say about the QoS no-go, I gather that the IPSec VPN will not be to cover -all- the data going over the T1, but rather only a subset of the hosts (e.g., finance servers) ? Or is part of the whole point that the Internet links feed directly into the router that houses the T1 and so there is leakage of Internet data across the T1, and the VPN will be there to protect against that ?

[If so, then you'll have to pull the "good" data off the router to an ethernet port, put it through the 501 and back into the router with either some PBR or with the router set up to bridge the relevant ports together. If you are running short of ethernet ports on the T1 router, then you would save a port by using a 506 or 506E, as those models can have multiple "logical" interfaces on one physical interface, with the interfaces distinguished by 802.1Q vlan tag. And the 506 and 506E are both fast enough to be able to handle a full-duplex T1.]

Of course your allowed to ask "are you sure"..lol

I should have been more specific about the latency, it is most likely only during business hours, which is, of course, when I need to tx/rx data across that link. Another thing that needs to be stated is that this network belongs to the city, and I work for the state, so I have no power to do anything to this network (indeed, I am more limited than a contractor would be, because cities, especially large ones, resent state "intrusion" into their realm; however, the site where the clients are is considered our domain... freaky). The situation is that I have an app that is so poorly written that it cannot traverse NAT, so I had to get creative with the solution. This city is connect to our state network via a P2P T1 line. The app resides on some servers in our core and the clients reside on the city's network. The kicker is that the clients are in a different location from where our T1 is located. Therefore we have to traverse part of the city's network (including that horrible T1) to get to our gear, and on to our network. Since the app will not work if NAT is involved, I am building a tunnel from a PIX 501 at their office to our gear, making their little group part of our network using our internal IP space. Kludgie, but workable apart from the latency issue.

-Richard

In article , Richard Graves wrote: :The situation is that I have an app that is so poorly :written that it cannot traverse NAT, so I had to get creative with the :solution.

:Since the app will not work if NAT is involved, I am building a :tunnel from a PIX 501 at their office to our gear, making their little group :part of our network using our internal IP space.

If by "internal IP space" you mean "same subnet at both ends" then you cannot do it with a 501: you need PIX 7.0's transparent firewall to work that scenario, and 7.0 is not supported on the 501.

If you just mean that you will get the address into an IP space that your routers are willing to send to directly without address translation (e.g., if the address translation would normally happen in the city's equipment) then you are okay.

This is what I meant :-)

I know that the config will work, my only worry is if the VPN will work correctly with the 400ms lag during the day.

We'll find out in the morning, I get to go see if it works or not. I'll let you know ;-)

-Richard

We have a VPN connection between a 501 and a 515. The latency is 500-1100 ms and packet loss can be as high as 50 %, but we have had no problems with the VPN tunnel. Of course using the tunnel is slow as hell, but otherwise it is working fine.

In article , Jyri Korhonen wrote: :We have a VPN connection between a 501 and a 515. The :latency is 500-1100 ms and packet loss can be as high :as 50 %, but we have had no problems with the VPN tunnel.

Yikes, where are you going that exposes that much latency??

We have a 501501 connection over a distance of 5500 kilometres (straight line -- further electronically.) Our latency is 77-83 ms round trip.

Yes, it seems that the amount of kilometers is less important than the location of those kilometers. We are running many VPN tunnels and the one with the above figures is the only where we have latency problems. The tunnel in question connects Helsinki, Finland to Shanghai, China and the traffic is being routed over public internet like this:

Finland - Sweden - USA - China

We can get to USA in 200 ms or so and the first hop in China is about the same. The rest of the latency (up to +900 ms) is generated by the internal routing of China.

Now that is the size network I want to work on! I always wanted to work on one of the "chase-the-sun" size WANs. :-)

Anyhow, I deployed my VPN solution today, and it worked liked a charm. It would have worked even better had I not forgot to put the "nat (inside) 0 access-list [VPN ACL]" statement in one of the routers, or caught this mistake sometime in the first two hours of troubleshooting...lol..thats what I get for chatting with people while I work.. ;-)

-Richard