3

I am new to Ipsec tunnels. I have successfully created a tunnel to a Cisco offsite router using a preshare key at a supplier.

In Endpoints 1 : I have the servers ip address and the remote servers ip address that I intend connecting to.

In Endpoint 2 : I have the same ip addresses as above

In the ipsec tunnel Endpoint I have listed the servers IP address and Endpoint 2 I have listed the Cisco router.

The tunnel comes up. (Its visible under monitoring and in Main Mode and Quick mode) In addition to that the supplier confirms that they can see our connection.

However when we try connect to one of the servers within their network, listed in endpoint 1 and 2 above, it does not connect.

The supplier claims that they have other clients connecting in this fashion and its not a problem on their side.

I have tried tracing the traffic in wireshark but wireshark only sees the traffic if I disable the Ipsec tunnel.

EDIT: I can see traffic to and from the tunnelendpoint when I try telnet into a server behind the tunnelendpoint. However the telnet session timesout before it is established. Wireshark trace

Any ideas?

Wize
  • 91
  • 6
  • Are you able to see any Active Tunnels through the MMC snap-in? Can you try running "netsh IPsec dynamic show mmsas" from an elevated command prompt and post back the result? – ngn Jul 27 '15 at 09:03
  • I am not sure which snap-in you are referring to.,I cant see active tunnels however the reults of the cmd are C:\Users\administrator>netsh IPsec dynamic show mmsas IKE Main Mode SAs at 2015/07/27 11:08:24 AM ------------------------------------------------------------------------------- Cookie Pair : 2742f5c68a2d0a7c:8da4f90017569739 Sec Methods : 3DES/SHA1/2/28800 Auth Mode : Preshared Key Source : 176.x.x.x , port 500 ID : 176.x.x.x Destination : 41.x.x.x , port 500 ID : 41.x.x.x – Wize Jul 27 '15 at 09:10
  • The tunnel endpoint should be your Cisco router and Endpoint 2 should be your server. – ngn Jul 27 '15 at 09:38
  • Just to clarify the Cisco router is the 41.x.x.x address and the 176.x.x.x is my server. I dont control the Cisco router. However I do have my server in both Endpoint 1 and 2 and the Cisco Router in the Tunnel endpoint. I also have their Servers in End Point 1 and 2. – Wize Jul 27 '15 at 09:48
  • That looks about right. After your tunnel is up, try generating some traffic to the servers you are trying to access (ping, maybe?). Setup filters in Wireshark to capture traffic between your machine and the server you want to connect to. If you are not able to see any traffic at all in Wireshark, this could be an issue with your IPsec policy filters. Ensure that your rules are Mirrored and that PFS is enabled only if it is enabled on the router as well. – ngn Jul 27 '15 at 09:55
  • Thanks, what do u mean by rules mirrored? and where can I find the Ipsec policy filters – Wize Jul 27 '15 at 10:00
  • I'm sorry I was assuming that you manually configured your IPsec policy using the native Windows interface. How have you defined policy rules and filters on your server? Are you using a Cisco VPN client to do this? – ngn Jul 27 '15 at 10:13
  • I did manually configure the IPsec policy, I used windows Firewall connection security rules. and the default ipsec security rules on the firewall. I havent used the Cisco Vpn client. Do I need to add routes? – Wize Jul 27 '15 at 10:26
  • Can I check something just to remove any assumptions. The telnet session is that from the machine that is also the ipsec endpoint on your side? – Drifter104 Aug 04 '15 at 21:57
  • @Drifter104 yes the telnet session is from our ipsec end point – Wize Aug 07 '15 at 13:28
  • What happens when you do a tracert to the ip you are trying to telnet to once the tunnel is up? Can you post the output? – Drifter104 Aug 07 '15 at 13:50
  • 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. – Wize Aug 07 '15 at 14:05
  • If that is what happens when the tunnel is up I would guess it is a routing issue. Once the tunnel is up do a route print and see if the destination subnet is shown. It could also be they block tracert but fingers crossed that isn't it – Drifter104 Aug 07 '15 at 22:49
  • I checked and cant see the route in route print. So I added one as follows 196.11.X.X 255.255.255.255 41.1.X.X 176.9.X.X Is there something I may be missing – Wize Aug 08 '15 at 22:50
  • I'm pretty sure that route should be generated by the configuration and then the tunnel being up. Did you double check the configuration that ngn mentioned. Reading what you have put above again his answer, there should be no duplication of information on that endpoint screen – Drifter104 Aug 10 '15 at 09:33

2 Answers2

2

I went throught this article to get a better understanding of what your configuration is. Your local computer (or the server from which the tunnel will be initiated) should be listed in "Endpoint 1" as well "local Tunnel Computer". The "remote tunnel computer" box should have the IP address of your router where the tunnel is terminated. The servers that you want to connect to on the other end should be listed in "Endpoint 2".

Since you are able to successfully negotiate security associations, I do not think any changes are required in your Tunnel configuration. However, please cross check your local and remote IP address. No traffic will be generated if there is a mistake in these filters. If possible, try to initiate traffic to your remote endpoints and run Wireshark with appropriate filters.

EDIT: I am attaching a screenshot here of IPsec traffic captured in Wireshark. You can clearly see Main Mode security associations being established first and Quick Mode being established whenever there is traffic flowing through the tunnel. I have intentionally removed the Source and Destination columns.

IPsec traffic captured through Wireshark

ngn
  • 333
  • 1
  • 10
  • I am 100% sure the tunnel is working. I am also sure that the network traffic is being routed through the tunnel (because when the tunnel is off I see the traffic in wireshark and when its on I dont. Wireshark cant see ipsec traffic) However I cant undertstand why none of the servers on the other side are responding to my telnet sessions on the available ports. – Wize Jul 28 '15 at 12:26
  • Actually, Wireshark is able to see IPsec traffic being generated, but not what the contents are. In fact, you can even see Quick Mode SA's being established and ESP packets being transmitted if traffic is flowing through. My suspicion is that there is no traffic flowing through the tunnel at all, because no traffic is being generated. – ngn Jul 29 '15 at 08:29
  • Please take a look at the wireshark trace above, added it into the question – Wize Jul 29 '15 at 19:40
  • Have you tried disabling virus scanners? – Phil McKerracher Jul 29 '15 at 23:52
  • I dont have any virus scanners on the machine. Windows defender is also off. I have also tried connecting with Shrew and disabling the firewall but the same thing happens – Wize Jul 30 '15 at 08:58
0

I have this problem too (Windows Server 2012R2 Evaluation) and I solved it with this workaround. The problem occurs when you have enabled NAT on the internet facing interface for internet access of the local LAN. The traffic generated in the local LAN with destination the remote LAN is NATted before the encryption. The Cisco receive this encrypted packet, decrypt it, but the source IP of the decrypted packet is the public IP address of the Windows Server. Because this is an error, the Cisco router discard the packet and increment the error count. You can see this counter in the Cisco router with the command show crypto ipsec sa detail and the counter appears in pkts decaps failed (rcv). Also, you can see the counters in the NAT statistics in the Windows Server.

Solution: in the Windows Server create a static route for the remote LAN via the loopback interface (from the DOS command line). Use the -P option to make the route permanent (persistent to restarts). For example, if the remote LAN is 10.245.0.0/16, the command is:

route -P add 10.245.0.0 mask 255.255.0.0 0.0.0.0 if 1

Unfortunately I could not find another method to avoid the NAT of the traffic destined to the remote LAN through the ipsec tunnel.

mangelo
  • 1