07-21-2008 08:22 AM - edited 03-11-2019 06:17 AM
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
Solved! Go to Solution.
07-22-2008 04:35 AM
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
07-21-2008 08:44 AM
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
07-21-2008 08:53 AM
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
07-21-2008 10:21 AM
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
07-21-2008 10:41 AM
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
07-21-2008 11:56 AM
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
07-21-2008 11:40 AM
Your configuration is very strange.
What are you going to do with it?
Could you give more information about your design?
07-22-2008 02:18 AM
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
07-22-2008 03:51 AM
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
07-22-2008 04:35 AM
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
07-22-2008 05:39 AM
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
07-22-2008 05:44 AM
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
07-22-2008 06:26 AM
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
07-22-2008 08:32 AM
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
07-25-2008 07:58 AM
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
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: