ASA VPN to PIX - UDP traffic goes unencrypted to outside...

rampf-gruppe · ‎05-13-2009

Hello!

I have a customer which does some dynamic L2L-VPNs from PIX501s to a 5510 ASA.

When the tunnel establishes th frst time everything is ok.

But after re-establishing it from the 501-side (because of DSL-forced-disconnection) TCP/ICMP-Traffic is ok.

UDP Traffic isn't routed anymore into the tunnel, the packets appear on the outside-interface! Unencrypted!

We saw this with etherreal and we can reproduce it.

Background: Server behind ASA communicates with devices behind PIX on fixed UDP-Port.

Is this a bug? How can we overcome this issue?

ASA has 8.0.(4)28, PIX is on 6.3(5)

Thank you for response.

Regards,

Patrick

Report Inappropriate Content · ‎05-19-2009

If there is no indication that an IPsec VPN tunnel comes up at all, it possibly is due to the fact that ISAKMP has not been enabled. Be sure that you have enabled ISAKMP on your devices. You may try enabling the NAT-T command on ASA. It is important to allow the UDP 4500 for NAT-T, UDP 500 and ESP ports by the configuration of an ACL because the PIX/ASA acts as a NAT device.

rampf-gruppe · ‎05-19-2009

Did you read my post?

Tunnel works perfect - until reestablishing it.

Afterwards, only TCP and ICMP goes into tunnel. UDP is passed without encryption to the outside interface (and without NAT!)

I am surely able to configure a IPsec VPN on a PIX (with any NATs and crypto-ACls etc...)

jeff.carr · ‎05-20-2009

The only reason I can think of for the UDP traffic to go unencrypted is that it no longer meets the criteria for "interesting" traffic. You mentioned that it is also not being translated, which would seem to fit that theory. I would suggest the translation rules be verified and the traffic you are seeing in your packet captures be confirmed.

I would also suggest that you verify the status of the tunnel on the ASA side. Confirm that if the tunnel is dropped on the PIX side, the tunnel is dropped and recreated on the ASA side.

cbark · ‎07-07-2009

Hi Patrick,

sorry for the late response but I just saw your entry.

I am 100% that the problem is due to the udp as a connectionless protocol and the fact that udp traffic generated to dst behind the pix.

Assuming those clients sending udp requests, I guess snmp, the ipsec tunnel is not up. The asa will look up the routing table and hits the default route and will forward it.

And you see a connection entry in sh conn.

So than the pix established the ipsec tunnel, all sas everything works fine, but not the udp traffic from the server to the udp dst beyond the pix.

Reason is the connection entry in the table of the asa. And as you said the servers that are doing the udp traffic using fixed ports will renew the connection in the connection table for ever.

Clear them and than it should work.

You might also adjust the udp timeout.

Or do prevent that traffic from being routed to the outside.

If that doesn't work the whole setup works as designed. I am not aware of a solution so far only clear the connection entry on the asa.

Rgds,

Christian

cbark · ‎07-07-2009

Forgot something.

You might configure a specific udp timeout for this special udp polling server maybe some seconds. Not tough the udp global timeout at all.

Maybe that helps.

rampf-gruppe · ‎07-07-2009

Hi Christian,

that explains the problem.

What I don't understand is the fact, that udp is - like you said - connectionsless, so every new udp-packet should pass the acl on interface and the crypto-acl.

And both should match.

So, if we assume udp is connection-less, why is there a connection-entry?

Does ASA make something "stateful" out of udp to be able to check reverse-traffic?

Besten Dank :-)

Patrick

cbark · ‎07-07-2009

Hi Patrick,

I meant with "connection less" that udp itself is connection less. But you can make the asa to use this as a connection oriented traffic.

Kind of that, but test it first in the lab!

policy-map global_policy

class inspection_default

inspect icmp

!

service-policy global_policy global

And the asa manages everything over the connection entry. That is the first thing it will be looked after.

The problem you have is that your udp server that sends the requests sends the same src/dst ip AND the same src/dst udp ports so it will exactly match the connection entry and renew it so it will never timeout.

Hope that answers your question.

Gerngeschehen,

Ciao

Christian

cbark · ‎07-07-2009

Hi Patrick,

sorry my config was about icmp.

So it doesn't affect the udp stuff.

Forget about the config I sent, but the rest of my post says the same.

In other words if the server that sends udp changes for exable the source udp port and the asa gets it, it will be a new connection and will go over the crypto ipsec sa.

Cheers,

Christian