Syn Timeout Issue.

Answered Question
Jul 21st, 2008

Hi Guys,


I'm hoping someone can help here.

I am getting these syn timeout issue on my asa 5510.



Jul 21 2008 16:19:04: %ASA-6-302013: Built outbound TCP connection 2576744 for outside:plug-2/25 (plug-2/25) to internal-vlan-20:coa-dun-db1/40643 (coa-dun-db1/40643)

Jul 21 2008 16:19:34: %ASA-6-302014: Teardown TCP connection 2576744 for outside:plug-2/25 to internal-vlan-20:coa-dun-db1/40643 duration 0:00:30 bytes 0 SYN Timeout


the following nat statements apply:

nat (internal-vlan-20) 1 access-list nat outside

!

access-list nat extended permit tcp object-group coa-dun-db object-group plug eq 123

access-list nat extended permit udp object-group coa-dun-db object-group plug eq ntp

access-list nat extended permit tcp object-group coa-dun-db object-group plug eq smtp

access-list nat extended permit ip any host x.x.64.133

access-list nat extended permit ip any host x.x.65.133

access-list nat extended permit tcp object-group coa-dun-back-net host sol-sco-hobbit1-ext eq 1984

access-list nat extended permit tcp object-group coa-dun-web-back host sol-sco-hobbit1-ext eq 123

access-list nat extended permit udp object-group coa-dun-web-back host sol-sco-hobbit1-ext eq ntp

access-list nat extended permit tcp host coa-dun-mon3-back any range www https

access-list nat extended permit udp host coa-dun-mon3-back host plug-1 eq domain

access-list nat extended permit udp host coa-dun-mon3-back host plug-2 eq domain

access-list nat extended permit tcp host coa-dun-mon3-back host plug-1 eq domain

access-list nat extended permit tcp host coa-dun-mon3-back host plug-2 eq domain

access-list nat extended permit ip x.x.93.32 255.255.255.248 host asa-ext

access-list nat extended permit ip x.x.86.72 255.255.255.248 host asa-ext

access-list nat extended permit icmp any any


Why are my connecitons not getting there.


Please help


Regards


Stephen

Correct Answer by husycisco about 8 years 7 months ago

Stephen,

In a normal configuration, the VPN traffic should take precedence in NAT&Global processing and you shouldnt have to remove specific traffic from a later NAT statement to make things work.

Also as I previously stated, including port definitions in network definition ACLs such as NAT, Interesting traffic, Split tunneling etc degrades the performance. By doing so, you are assigning the "filtering" task to Routing&Switching Process. That would be acceptable in a router but still not the best practise, that they are designed for doing routing (They support BBR while ASA does not). Routing&Switching process should just decide to R&S which packet in which buffer of which interface to where. Filtering should actually take place "before" that process, by filtering packets before they get into relevant buffer and enter the R&S process. And this is accomplished via ACLs assigned to interfaces.



Here is the config that I suggest


access-list vlan20_access_in extended permit tcp object-group coa-dun-db object-group plug eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-db object-group plug eq ntp

access-list vlan20_access_in extended permit tcp object-group coa-dun-db object-group plug eq smtp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back object-group plug eq ntp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq smtp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back any range www https

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq domain

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back object-group plug eq domain

access-list vlan20_access_in extended permit tcp object-group coa-dun-back-net host us-sco-hobbit1-ext eq 1984

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back host us-sco-hobbit1-ext eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back host us-sco-hobbit1-ext eq ntp

access-list vlan20_access_in extended permit ip x.x.93.32 255.255.255.248 host asa-ext

access-list vlan20_access_in extended permit ip x.x.86.72 255.255.255.248 host asa-ext

access-group vlan20_access_in in interface internal-vlan-20


access-list vlan20_nat0_outbound permit ip object-group vpn-allowed-source object-group coa-sco-net

nat (internal-vlan-20) 1 0 0

nat (internal-vlan-20) 0 access-list vlan20_nat0_outbound


Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
stephen.stack Mon, 07/21/2008 - 08:44

Some more info.


My problem is that i can depending on the NAT statement below i can get traffic to the internet/ VPN or not.


nat (internal-vlan-20) 1 access-list nat outside

nat (internal-vlan-20) 1 access-list nat


1st: traffic accross VPN - not internet

2nd: traffic to internet - not accross VPN


All based on ACL above.


Now i'm really confused.


Thanks Stephen

husycisco Mon, 07/21/2008 - 08:53

Hello Stephen,

Using "outside" term in NAT is generally involved in complex VPN hairpinning, and I dont think that you have to use it.

You say that you are not getting there. Getting from and to where? It also depends on the direction that you apply that ACL to interface.

Please simply describe what you want to have and what you cant at the moment, and post your sanitized config.


Regards

stephen.stack Mon, 07/21/2008 - 10:21

Hi


What do you mean by VPN 'hairpinning'?


Basically when i put the 'outside' term at the end of the nat statement, i can get traffic from my inside lan to the remote lan over the IPsec tunnel. But - when this term is at the end of the nat statement - hosts have difficulty getting internet access. The SYN issue above is a result of this.

When i remove the 'outside' term internet access works but VPN traffic does not flow from one lan to another. The VPN acl must be correct beacuse traffic flows when the outside statement is put back.


I must say that i have inherited this config, so i don't understand some of the reasons for the config. I could wipe and recreate the config, but i am hestitant to do this beacuse of the environment it is in.


Thanks & Regards


Stephen

husycisco Mon, 07/21/2008 - 10:41

Stephen,

"What do you mean by VPN 'hairpinning'? "

Long story and it is not related with your issue. But the reason why it is meant to be used in your config, as I understand after your explainations about what happens when you do something, is to NAT the VPN traffic coming from remote office, If this is really made on purpose, made by someone who knows what he is doing.

As long as the cases are not 1)There are overlapping private networks between sites, 2)Applications exist that has to see traffic coming from specific addresses, outside NAT should not be used.

In addition, any network statements including port statement in its configuration will slightly degrade the performance, just as you encounter when you apply it, since the router now has to analyze and compare the port matches of every single packet arriving to relevant interface. This is definitely not the best practise.

Before making CLI suggestions, I should know about your config (sanitized one), or at least the interface which your inside hosts reside and the interface on which you terminate the VPN connection (with security levels), and current NAT and global statements.


Regards


stephen.stack Mon, 07/21/2008 - 11:56

hi,


I checked out VPN hairpinning - clever stuff!


There are no overlapping networks.

There are also no specific application requirement's


I am really hoping you can help with this, I am totally not a pix/asa expert.


Can you give me your email and i'll get the config to you. it is elaborate and i don't want it up here. even though it is sanitised.


Thanks again


stephen

a.alekseev Mon, 07/21/2008 - 11:40

Your configuration is very strange.

What are you going to do with it?

Could you give more information about your design?


stephen.stack Tue, 07/22/2008 - 02:18

Hi,


Ya tell me about it :)

I am taking ages to get my head around it. I have sanitized the config to post it here. Have a look and let me know what you think. This is getting a bit urgent now.


Thanks


Stephen



Attachment: 
stephen.stack Tue, 07/22/2008 - 03:51

ok guys, thing i got it.

I have removed the outside statement from the end of the nat statement. Then i rejigged my nat acl to this

access-list nat extended permit tcp object-group coa-dun-db object-group plug eq 123

access-list nat extended permit udp object-group coa-dun-db object-group plug eq ntp

access-list nat extended permit tcp object-group coa-dun-db object-group plug eq smtp

access-list nat extended permit tcp object-group coa-dun-web-back object-group plug eq 123

access-list nat extended permit udp object-group coa-dun-web-back object-group plug eq ntp

access-list nat extended permit tcp object-group coa-dun-web-back object-group plug eq smtp

access-list nat extended permit tcp object-group coa-dun-web-back any range www https

access-list nat extended permit tcp object-group coa-dun-web-back object-group plug eq domain

access-list nat extended permit udp object-group coa-dun-web-back object-group plug eq domain

access-list nat extended permit tcp object-group coa-dun-back-net host us-sco-hobbit1-ext eq 1984

access-list nat extended permit tcp object-group coa-dun-web-back host us-sco-hobbit1-ext eq 123

access-list nat extended permit udp object-group coa-dun-web-back host us-sco-hobbit1-ext eq ntp

access-list nat extended permit ip x.x.93.32 255.255.255.248 host asa-ext

access-list nat extended permit ip x.x.86.72 255.255.255.248 host asa-ext


Note i removed the icmp any any statement.


To my reasoning - by allowing icmp thru this acl, the traffic was being directed out the outside interface and not thru the VPN, when i removed it traffic went thru the VPN.


Hope that makes sense - any other notes on this are welcome.


Stephen

Correct Answer
husycisco Tue, 07/22/2008 - 04:35

Stephen,

In a normal configuration, the VPN traffic should take precedence in NAT&Global processing and you shouldnt have to remove specific traffic from a later NAT statement to make things work.

Also as I previously stated, including port definitions in network definition ACLs such as NAT, Interesting traffic, Split tunneling etc degrades the performance. By doing so, you are assigning the "filtering" task to Routing&Switching Process. That would be acceptable in a router but still not the best practise, that they are designed for doing routing (They support BBR while ASA does not). Routing&Switching process should just decide to R&S which packet in which buffer of which interface to where. Filtering should actually take place "before" that process, by filtering packets before they get into relevant buffer and enter the R&S process. And this is accomplished via ACLs assigned to interfaces.



Here is the config that I suggest


access-list vlan20_access_in extended permit tcp object-group coa-dun-db object-group plug eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-db object-group plug eq ntp

access-list vlan20_access_in extended permit tcp object-group coa-dun-db object-group plug eq smtp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back object-group plug eq ntp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq smtp

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back any range www https

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back object-group plug eq domain

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back object-group plug eq domain

access-list vlan20_access_in extended permit tcp object-group coa-dun-back-net host us-sco-hobbit1-ext eq 1984

access-list vlan20_access_in extended permit tcp object-group coa-dun-web-back host us-sco-hobbit1-ext eq 123

access-list vlan20_access_in extended permit udp object-group coa-dun-web-back host us-sco-hobbit1-ext eq ntp

access-list vlan20_access_in extended permit ip x.x.93.32 255.255.255.248 host asa-ext

access-list vlan20_access_in extended permit ip x.x.86.72 255.255.255.248 host asa-ext

access-group vlan20_access_in in interface internal-vlan-20


access-list vlan20_nat0_outbound permit ip object-group vpn-allowed-source object-group coa-sco-net

nat (internal-vlan-20) 1 0 0

nat (internal-vlan-20) 0 access-list vlan20_nat0_outbound


Regards

husycisco Tue, 07/22/2008 - 05:39

Following is missing from my above suggestion


access-list vlan20_access_in extended permit ip object-group vpn-allowed-source object-group coa-sco-net

stephen.stack Tue, 07/22/2008 - 05:44

Excellent, thanks for that last line. I was just about to figure out why it was not working.

So thats it working. Thanks for you time on this one. And i really appreciate the new config and the notes to boot.


You spoke a little about performance. Just a few minutes ago my manager came over and said that there is a serious performance issue on the vpn. Getting about 200k on file transfer on a 40Mb link. Would anything you have seen on the config be the cause of this.


Thanks again


Stephen

husycisco Tue, 07/22/2008 - 06:26

Stephen,

You are welcome.

Is it working with the config that I suggested or with the one that you modified?

200K so low for 40Meg that it cant only be caused of poor NAT statements. How did your manager get that stataistic and when? Was that before or it started after changing a config?

Please upload the final config for a last check, rest of the config looks OK.

For further investigation,

1)Run "clear int outside" then after 5 minutes "sh int outside", then check the 1 Minute and 5 minute input/output rates to see if the 40 Meg is overhelmed by other traffic. Also look at the input and output ques and check if ques get full

2)run "clear crypto ipsec sa counters", then start copying a file from local site to remote site, then after the copying is finished, run "sh crypto ipsec sa" and paste the results and lets see the dropped and fragmented amount of packets.

3)Btw, if you made a change in NAT statements, issue "clear xlate"

Regards

stephen.stack Tue, 07/22/2008 - 08:32

Hi,


Ya it's working with the config you gave me. That one makes much more sense to me. I also copied it and put it on the other side of the VPN. All is well now.


Let me come back with those details. first glance says nothing overwhelming on interfaces or cryptos.


Cheers


Stephen

stephen.stack Fri, 07/25/2008 - 07:58

Hi,


Sorry for not getting back to you sooner. Would you beleive that by upgrading the ASAs from 7.0 to 8.0 the bandwidth increased to over 40Mbps.


Thanks for all your help again


Stephen

husycisco Fri, 07/25/2008 - 09:26

"Would you beleive that by upgrading the ASAs from 7.0 to 8.0 the bandwidth increased to over 40Mbps"

Interesting. Glad to hear that your issue is resolved.


You are welcome :)



Actions

This Discussion