I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
That is why I asked.
On Mon, Nov 14, 2011 at 09:08:05PM +0400, Lucas wrote:
I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
It seems you have your layering wrong. IPSec operates on IP protocol, below UDP and TCP. Only IKE, the key exchange, protocol works on UDP. Maybe you thought about different technology? For VPN, OpenVPN provided in Fedora support TCP transport.
Hi,
Fedora ships the open source "vpnc" client which supports the Cisco VPN environment. I'm using it daily and it works for me without any problems.
There is also a proprietary client from Cisco: http://www.cisco.com/en/US/products/sw/secursw/ps2308/index.html .
On 11/14/2011 06:34 PM, Tomasz Torcz wrote:
On Mon, Nov 14, 2011 at 09:08:05PM +0400, Lucas wrote:
I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
It seems you have your layering wrong. IPSec operates on IP protocol, below UDP and TCP. Only IKE, the key exchange, protocol works on UDP. Maybe you thought about different technology? For VPN, OpenVPN provided in Fedora support TCP transport.
To clarify the misunderstanding: Cisco's VPN concentrator provides the feature "IPSec over TCP".
Unfortunately, vpnc does not support it:
man 8 vpnc: [...] --natt-mode <natt/none/force-natt/cisco-udp> Which NAT-Traversal Method to use: · natt -- NAT-T as defined in RFC3947 · none -- disable use of any NAT-T method · force-natt -- always use NAT-T encapsulation even without presence of a NAT device (useful if the OS captures all ESP traffic) · cisco-udp -- Cisco proprietary UDP encapsulation, com‐ monly over Port 10000 Note: cisco-tcp encapsulation is not yet supported Default: natt conf-variable: NAT Traversal Mode <natt/none/force-natt/cisco-udp> [...]
So it looks like that for your use case (connecting to a Cisco VPN using IPSec over TCP) you have to use Cisco's proprietary client.
Best regards, Christian
Hi.
On Mon, 14 Nov 2011 18:34:04 +0100, Tomasz Torcz wrote
It seems you have your layering wrong. IPSec operates on IP protocol, below UDP and TCP. Only IKE, the key exchange, protocol works on UDP. Maybe you thought about different technology? For VPN, OpenVPN provided in Fedora support TCP transport
The Cisco VPN client (and vpnc) can encapsulate ESP in UDP, to help transmission through firewalls, NAT and the like, the operative term for that is NAT-T. The Cisco VPN client can also use TCP encapsulation, although I think that requires support on the terminating device as well (it will not work by default).
I've never used it in practice.
On Mon, 2011-11-14 at 21:08 +0400, Lucas wrote:
I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
That's entirely stupid. The Cisco "IPsec over TCP" is basically the *same* as UDP, except it fakes a TCP header on each packet in order to make it pass through crappy firewalls and NAT which only supports TCP.
If your IT department think that UDP needs to be blocked "for the security reason", then it sounds like they are incompetent and should be fired. Or just taken out back and shot.
We *have* had Cisco's IPSec over TCP working; it's not particularly difficult. However, we never really worked out how to make it work nicely on Linux; the kernel really *really* wants to eat all TCP packets and will give a TCP RST to any connection it doesn't think is open. Any mechanism to effectively operate TCP in userspace, which is what we need to do, would be very much frowned upon.
On 11/16/2011 04:49 PM, David Woodhouse wrote:
On Mon, 2011-11-14 at 21:08 +0400, Lucas wrote:
I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
That's entirely stupid. The Cisco "IPsec over TCP" is basically the *same* as UDP, except it fakes a TCP header on each packet in order to make it pass through crappy firewalls and NAT which only supports TCP.
If your IT department think that UDP needs to be blocked "for the security reason", then it sounds like they are incompetent and should be fired. Or just taken out back and shot.
We *have* had Cisco's IPSec over TCP working; it's not particularly difficult. However, we never really worked out how to make it work nicely on Linux; the kernel really *really* wants to eat all TCP packets and will give a TCP RST to any connection it doesn't think is open. Any mechanism to effectively operate TCP in userspace, which is what we need to do, would be very much frowned upon.
Dear All.
The question was not how good or bad is Cisco IPSec over TCP, personally I do not like politics of that company. I also can't complain to our IT, because they just do not want to forward any udp port to internal network. They are just happy that cisco manages to wrap udp to tcp, and cisco vpn works on windows. That is all.
The problem is that it looks like I can't compile it under F16, and can't find any normal manual in internet. So my question was - if anyone has done it under Fedora16 32bit, and if yes, please share with me your experience.
Of course, I can install winxp on virtualbox, and I can use windows version, BUT I do not like it.
On Wed, 16 Nov 2011, David Woodhouse wrote:
On Mon, 2011-11-14 at 21:08 +0400, Lucas wrote:
I am talking about ipsec over TCP.
Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp.
That's entirely stupid. The Cisco "IPsec over TCP" is basically the *same* as UDP, except it fakes a TCP header on each packet in order to make it pass through crappy firewalls and NAT which only supports TCP.
If your IT department think that UDP needs to be blocked "for the security reason", then it sounds like they are incompetent and should be fired. Or just taken out back and shot.
We *have* had Cisco's IPSec over TCP working; it's not particularly difficult. However, we never really worked out how to make it work nicely on Linux; the kernel really *really* wants to eat all TCP packets and will give a TCP RST to any connection it doesn't think is open. Any mechanism to effectively operate TCP in userspace, which is what we need to do, would be very much frowned upon.
Openswan had thought about supporting the same silly thing to avoid stupid sysadmins using its KLIPS IPsec stack. We have not done this so far. The problem is once you go this way, you are basically engaging in a warfare that culminates in a "skype" type protocol.
Having said that, for DNS (with DNSSEC) facing similar issues, doing raw DNS over 443 works pretty well, and unbound SVN already has alpha support for doing dns-over-real-https. Chrome supports dnssec-blobs-in-x509-options.
At what point do we stop building another onion around the internet? Everyone knows the internet should not be tunneled over tcp 443. Everyone knows when your nat on the net your're not on the net. At some point, we are going to have to leave those severely broken networks behind.
Paul
Dne 16.11.2011 18:13, Paul Wouters napsal(a):
At what point do we stop building another onion around the internet? Everyone knows the internet should not be tunneled over tcp 443. Everyone knows when your nat on the net your're not on the net. At some point, we are going to have to leave those severely broken networks behind.
http://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH
Matěj
On Wed, Nov 16, 2011 at 12:49:41PM +0000, David Woodhouse wrote:
We *have* had Cisco's IPSec over TCP working; it's not particularly difficult. However, we never really worked out how to make it work nicely on Linux; the kernel really *really* wants to eat all TCP packets and will give a TCP RST to any connection it doesn't think is open. Any mechanism to effectively operate TCP in userspace, which is what we need to do, would be very much frowned upon.
Why not use a tun/tap interface set up with a private ip address which the vpn application causes to be masqueraded by the host? That should work and be portable across all kernel versions.
-ben
On Thu, 2011-11-17 at 11:10 -0500, Benjamin LaHaise wrote:
Why not use a tun/tap interface set up with a private ip address which the vpn application causes to be masqueraded by the host? That should work and be portable across all kernel versions.
Yeah, that's one of of the options. But still you have to set up NAT on the host. And make sure you don't conflict with any IP address ranges which might appear on local networks, or on the VPN. It doesn't really meet the "set it up nicely" criterion :)
If you can screw with iptables rules to set up NAT, you might as well just screw with iptables rules to block and capture the TCP packets you want. Either way, it's a pain in the arse.
-
Benjamin LaHaise -
Christian Krause -
David Woodhouse -
Lucas -
Matej Cepl -
Paul Wouters -
Ralf Ertzinger -
Tomasz Torcz