cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7148
Views
35
Helpful
16
Replies

IPSEC Tunnel only works one way

JamesS4
Level 1
Level 1

Hi All,

Having issue with IPSEC tunnel.  I only control our side, other side is vendor side.

 

If we initiate connection to them (e.g. telnet) we can connect and pass traffic with no issue.  If they try to telnet to us, they get timeout.  they say that the traffic is going through the tunnel, but they are not getting any return traffic.  I suspect either 1) we are missing a route, or 2) we are missing some kind of config wrt NAT.  I have attached a sanitized version of our config. 

 

We have IPSEC tunnel on outside Internet interface GI0/0/0 from our public address 38.38.38.98 to vendor side 198.198.4.38, which is working fine.

 

We can successfully connect (e.g. telnet) from our server 10.10.10.50 on inside interface GI0/1/2 across the tunnel to target host 198.198.4.51.

 

But 198.198.4.51 cannot initiate a telnet connection to 10.10.10.50.

 

Any obvious reason why?  Thank you! 

 

1 Accepted Solution

Accepted Solutions

Hello  JamesS4,

be aware of the static NAT statement

>> ip nat inside source static tcp 10.10.10.50 30001 38.38.38.98 30001 extendable

 

if remote site attempts to access TCP port 30001 instead of TCP port 23 this static NAT is triggered and this would explain why you see packets from WAN address 38.38.38.98 to remote IP address out of the VPN.

 

Check with the other side people what TCP port they are trying to access.

Also if available use a different internal host in network 10.10.10.0/24 that is not object of static NAT for additional tests with the other side.

 

Hope to help

Giuseppe

 

View solution in original post

16 Replies 16

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello JamesS4,

the ACL for defining interesting traffic to be encrypted should contain only the traffic flows sent from your side.

Your ACL VPN_ACL specifies the flows in both directions. This is not correct.

 

ip access-list extended VPN_ACL
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.50
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.51
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.52
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.53

! I would remove the following statements as those are needed on the other side router
permit ip host 198.198.4.50 10.10.10.0 0.0.0.255
permit ip host 198.198.4.51 10.10.10.0 0.0.0.255
permit ip host 198.198.4.52 10.10.10.0 0.0.0.255
permit ip host 198.198.4.53 10.10.10.0 0.0.0.255

!

 

The other side ACL should contain only the following lines

permit ip host 198.198.4.50 10.10.10.0 0.0.0.255
permit ip host 198.198.4.51 10.10.10.0 0.0.0.255
permit ip host 198.198.4.52 10.10.10.0 0.0.0.255
permit ip host 198.198.4.53 10.10.10.0 0.0.0.255

 

The ACLs on the two sides should be the mirror of each other. This is not possible with your current ACL.

 

Hope to help

Giuseppe

 

your suggestion was the way it was originally implemented, but I added only as an attempt to resolve the issue.  I will remove them again.  This will not resolve the problem however. 

 

Updated ACL looks like this now:

 

ip access-list extended VPN_ACL
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.50
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.51
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.52
permit ip 10.10.10.0 0.0.0.255 host 198.198.4.53

Hello JamesS4,

I couldn't know you had the right ACL in place at the beginning.

However, now your configuration should be fine on your side including the NAT configuration as you have the correct deny statements for traffic that should go over the IPSec tunnel.

 

 

Hope to help

Giuseppe

 

Oh, completely understood, I hope it was not implied you were to know anything other than what information I've provided.

 

I am a little confused though -- my thinking was that an extraneous permit statement in the VPN ACL should make no difference?  would having the lines that I've since removed definitively cause any sort of issue?

 

Also, just to give context -- at the time I added those lines, I also added the deny statements to the LAN NAT policy:

 

deny ip host 198.198.4.50 10.10.0.0 0.0.255.255
deny ip host 198.198.4.51 10.10.0.0 0.0.255.255
deny ip host 198.198.4.52 10.10.0.0 0.0.255.255
deny ip host 198.198.4.53 10.10.0.0 0.0.255.255

 

 

So, it is possible I fixed the issue with NAT and then broke it again with the erroneous permit VPN ACLs?  I don't have any insight right now if this is working as I've asked the other side to re-attempt connection but I've no response yet.

 

Is routing not an issue here at all?

I agree with my colleagues that you do not need the extra lines that you added to your VPN ACL and agree that you would be better off without them. It is a bit difficult to know if they would cause a problem. On the one hand they are extraneous, they would never be matched, and they seem harmless. But on the other hand as has been mentioned during the negotiation for crypto the ACL on both ends should match. With these extra lines they do not match and it is difficult to know what effect this might have. So my advice is to remove the lines.

 

When I first read the post I thought that the problem might be that there is one way traffic on the VPN. I have seen symptoms like that many times on site to site VPN. I have seen that caused by routing issues and caused by NAT issues. Your routing and your NAT seem right (though I am a bit curious about your second default route). And as I read the entire post I do not think it is really one way traffic. If I am understanding correctly you get successful two way traffic if you initiate the traffic (telnet) to them. But if they attempt to initiate the telnet then it fails. Am I understanding correctly? Would it be possible to get the output of show crypto ipsec sa during a session when you are successful in the telnet and then output of the command during a time when they are attempting to initiate the telnet and it is not working?

 

HTH

 

Rick

HTH

Rick

Thanks for the response Rick.

 

Re: matching ACLs on both sides, I think it should at least be noted that I have no idea what is I am negotiating with on the other end of this ipsec tunnel and I am rather sure that it is not a Cisco device.  Regardless, the extraneous lines are gone now.

 

Your assessment is correct overall.  Two-way traffic is successful if we initiate the session. If they initiate the session it is not, and they claim that they are not getting return traffic from us.  So it is one way traffic, but only from one direction.  so.. 3/4 traffic overall?  =)

 

Thank for the confirmation on NAT and routing.  I am not well versed in this and I wondered if I was missing something quite obvious.  The second default route is in reference to our secondary Internet connection, which we would fail over to if the primary becomes unavailable.  The VPN would not work in this scenario, so I omitted the details surrounding that.

It would be interesting to know what type of device is your peer. But almost certainly does not matter. I am curious about the relationship of the peer address (198.198.4.38) and the addresses that the VPN attempts to access 198.198.4.50, 51, 52, 53. It almost suggests that these public addresses get translated by your remote peer into something private. And that makes me wonder if there might be some issue on their side about how to translate when their device is initiating the traffic.

 

So far in talking about the VPN you have talked about telnet. Is telnet the exclusive type of traffic on the VPN? Or are other types of traffic also used?

 

Have you tested a scenario where you have initiated telnet, been successful, and then immediately they attempt to initiate telnet?

 

HTH

 

Rick

 

 

HTH

Rick

Telnet is not the exclusive traffic, but it's just a good way for us to verify connectivity.  It will be FIX session traffic.

 

I assume you are quite right that the vendor is NATing on their end, but I have no insight into that.

 

Re: the test scenario you suggest, we have done that but to no avail -- I feel confident the tunnel is up when they are attempting to connect.

 

Is there some way we can conclusively say that our side is not the issue?  Right now we are being blamed and I don't have the depth of knowledge to definitively say otherwise.

 

I have attempted to do a packet capture but it is strange.  When I telnet (successfully) from 10.10.10.50 to 198.198.4.51, I don't see anything in the capture.  On the other hand, I do capture some packets like this (and only this):

 

# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 66 0.000000 38.38.38.98 -> 198.198.4.53 0 BE TCP

 

I don't know 100% but I believe these are from their attempts to connect to us?  My concern is that the return traffic is getting routed to through the Internet connection and not the VPN tunnel?  Also, re: the NAT....  the idea is that we are not supposed to do any NAT at all, and we show to them through the tunnel as 10.10.10.50.  I believe it's working as designed, just concerned that somehow its not working when they are the initiating connector.

 

This is my capture setup:

 

ip access-list extended BUF-FILTER

permit ip any host 198.198.4.51

permit ip any host 198.198.4.52

permit ip any host 198.198.4.53

permit ip host 198.198.4.51 any

permit ip host 198.198.4.52 any

permit ip host 198.198.4.53 any

permit esp any host 198.198.4.51

permit esp any host 198.198.4.52

permit esp any host 198.198.4.53

permit esp host 198.198.4.51 any

permit esp host 198.198.4.52 any

permit esp host 198.198.4.53 any

 


monitor capture buffer BUF filter access-list BUF-FILTER

monitor capture point ip cef POINT Gi0/0/0 both

 

 

I have several comments:

- at this point it is difficult to say conclusively that the problem is not on your side. 

- packet capture on Gig0/0/0 should not see any traffic with your host source address or the telnet remote address. At the interface the telnet would be inside an encrypted ESP packet. I think packet capture on the vlan would be more productive.

- there have been some changes made in the config. It might be nice to see a fresh copy of the config.

- I would suggest some testing that would do the following:

-- clear crypto ipsec sa (so that we are not looking at results of things that have already happened)

-- show crypto ipsec sa (to get a baseline of the vpn status)

-- have the peer attempt telnet

-- show crypto ipsec sa (to see what has come through the tunnel)

- it might be helpful to see the output of show ip route at the time that the remote peer is attempting telnet.

 

HTH

 

Rick

HTH

Rick

Hello JamesS4,

I don't think there is a routing issue or the session started from your side would fail too.

 

Ask the other company if they have configured any form of ACLs or firewall features like Zone Based Firewall that can affect which side can start the communication.

note: an ACL can check for which side starts a TCP connection using the established keyword.

Allowing only a TCP flow with established keyword means only the other side starts the TCP connection sending the SYN flag

 

Hope to help

Giuseppe

 

 

So using packet capture, I think I have some sense of what is happening.  I setup one packet capture on GI0/0/0, and another one on VLAN.  Then I telnet connected from 10.10.10.50 to 198.198.4.51, successfully.  Then I asked the vendor to telnet connect to 10.10.10.50 from 198.198.4.53.

 

The captures on VLAN 10 show traffic for both:


59 66 302.780951 10.10.10.50 -> 198.198.4.51 0 BE TCP
60 66 307.312972 10.10.10.50 -> 198.198.4.53 0 BE TCP

the capture on GI0/0/0 shows nothing but this:

0 66 0.000000 38.38.38.98 -> 198.198.4.53 0 BE TCP

 

Based on our other thread, Giuseppe, I think we can expect NOT to see any VPN traffic on GI0/0/0, so the fact that traffic to 198.198.4.53 shows up is bad.

 

I think the implication is that traffic coming from 198.198.4.53 is able reach 10.10.10.50 but return traffic is getting sent back over the Internet, not the tunnel, and that's why this is broken.  But if that's the case then why??  the Internet NAT ACL is set specifically to reject anything from  10.10.x.x network so it should send it un NATed through the tunnel.  Any ideas?! 

Hello JamesS4,

I am reviewing the configuration file

a)

you are using the tunnel mode option this means VPN traffic should be ESP between specified endpoints

 

>>crypto ipsec transform-set TransformSet esp-aes 256 esp-sha-hmac
>>mode tunnel
!

 

b) the NAT ACL

ip access-list extended LAN_NAT_POLICY
deny ip 10.10.0.0 0.0.255.255 10.10.0.0 0.0.255.255
deny ip 10.10.0.0 0.0.255.255 host 198.198.4.50
deny ip 10.10.0.0 0.0.255.255 host 198.198.4.51
deny ip 10.10.0.0 0.0.255.255 host 198.198.4.52
deny ip 10.10.0.0 0.0.255.255 host 198.198.4.53
deny ip host 198.198.4.50 10.10.0.0 0.0.255.255
deny ip host 198.198.4.51 10.10.0.0 0.0.255.255
deny ip host 198.198.4.52 10.10.0.0 0.0.255.255
deny ip host 198.198.4.53 10.10.0.0 0.0.255.255
permit ip 10.10.0.0 0.0.255.255 any

 

Again the ACL should contain only traffic flows from your inside to outside

the lines

deny ip host 198.198.4.50 10.10.0.0 0.0.255.255
deny ip host 198.198.4.51 10.10.0.0 0.0.255.255
deny ip host 198.198.4.52 10.10.0.0 0.0.255.255
deny ip host 198.198.4.53 10.10.0.0 0.0.255.255

 

are not needed

but I don't see they can cause traffic to be sent NATTED and out of the IPSEC VPN.

I would suggest to remove those lines to have a correct configuration, but I'm afraid this does not solve the issue.

 

What is strange is the different behaviour if traffic is started from your internal network or it is started from the remote site.

From the configuration you have provided on your router you are not using zone based firewall or other security features ( I mean defining security zones and policy-map type inspect between zone pairs)

 

Hope to help

Giuseppe

 

you are correct that we have no zone based firewall or security.

 

The lines you suggest to delete are extraneous lines, just grasping at straws. I will remove them.

 

I feel that perhaps the issue lies in something to do with them being the initiator and therefore coming from outside to inside connection.  Essentially, we are targeting an inside address through an outside interface.  Perhaps that I need to give them an outside public address?

Hello  JamesS4,

be aware of the static NAT statement

>> ip nat inside source static tcp 10.10.10.50 30001 38.38.38.98 30001 extendable

 

if remote site attempts to access TCP port 30001 instead of TCP port 23 this static NAT is triggered and this would explain why you see packets from WAN address 38.38.38.98 to remote IP address out of the VPN.

 

Check with the other side people what TCP port they are trying to access.

Also if available use a different internal host in network 10.10.10.0/24 that is not object of static NAT for additional tests with the other side.

 

Hope to help

Giuseppe

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco