I have a Linux server (CentOS 5.5) that has direct access to the Internet with a fixed IP address. That is, the IP address is 200.29.X.Y. The gateway was given by the datacenter (200.29.X.Z) and the connection works perfect.
I need to connect to a another machine located on a remote LAN. We agreed on doing it through a VPN, so they configured a tunnel (IPsec using a preshared key) and they gave us all the information (peer, encryption domain, phase 1 properties, and phase 2 properties).
The problem is that my machine is not behind a firewall, and I don't have access to my datacenter's firewall… So the firewall must be created on the same machine (using any VPN command line software).
The problem is that if my machine has the firewall (and configures the VPN), the peer would be the same encryption domain (that is, the same IP address for the peer and the encryption domain)…
The other part told me that this is wrong and using this configuration their firewall does not know to where send out the responses (since the encryption domain is the same peer).
Trying to solve this, I created a virtual Ethernet interface called eth0.4 that has a local IP address, 192.160.0.4; and I told the other part to configure this as my encryption domain, but still it does not work.
Doing some local tests, from the internal virual IP address, 192.160.0.4, I cannot ping my real IP address, 200.29.X.Y (ping -I eth0.4 200.29.X.Y)… I added some forwarding rules on iptables, but still my internal IP address cannot communicate with my real IP address… So I think this "virtual local IP address" will not solve my problem (unless I added some incorrect forwarding rules).
I'm using openswan for configuring the VPN and accoding to the oher part, they receive the phase I details, they are correct, but there is a problem with the answer… so the tunnel is never made (in fact, phase I never completes).
010 "net-to-net" #1: STATE_MAIN_I1: retransmission; will wait 20 s for response
010 "net-to-net" #1: STATE_MAIN_I1: retransmission; will wait 40 s for response
010 "net-to-net" #1: STATE_MAIN_I1: retransmission; will wait 40 s for response
010 "net-to-net" #1: STATE_MAIN_I1: retransmission; will wait 40 s for response
031 "net-to-net" #1: max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message
000 "net-to-net" #1: starting keying attempt 2 of an unlimited number, but releasing whack
forever…
The openswan log does not give me more information (it sends the correct things but no response), and tcpdump allways tells me that I send packets but no answers…
Any suggestions?
Best Answer
If I'm understanding correctly, the other party is saying that they cannot terminate the tunnel to the address that's configured as the target network for the tunneled data. This depends on the capabilities of their device - do you know what manufacturer it's from?
Regardless of concerns over the remote network definition and their issues with their system trying to put the tunnel's ESP packets back into the tunnel, they aren't even responding to your phase 1 packets - this connectivity needs to be looked at first. Tell them to start answering your ISAKMP packets, then deal with the IPSec remote networks once that's working.