Re: is access-list the way to go?

l4nier · ‎07-17-2003

I have a situation with a customer of ours who is running the Nortel Contivity VPN. I am having troubles connecting to them. In my logs I see the following error:

2003-07-17 15:23:51 Local4.Critical 192.168.20.1 %PIX-2-106006: Deny inbound UDP from 63.70.119.69/137 to 216.191.146.84/137 on interface outside

They have given me the vpn ip as 63.70.119.67 yet these udp packets are coming back from 63.70.119.69.

Unfortunately their firewall guy doesn't have any support and isn't sure how to handle this. We have a bit of an emergency and really need to get in there.

How can I open this up to this company only? Can I use access-list? If so what commands would I need to allow that subnet above to connect to our internal network.

Thanks so much!

Louanne Fournier

lfournier@nexterna.com

l.mourits · ‎07-17-2003

Louanne,

I think you should be somewhat more specific on what you are trying to achieve exactly. As I understand it right now you want to establish a so-called site to site VPN between your PIX and this Nortel contivity VPN Gateway.

The log you provides indicates a UDP packet travelling in, which is denied, so, this is not an encrypted packet at all, so it seems to me that you do not have a vpn tunnel established right now.

There are some items that you will at least need to have in your configuration for establishing a site-to-site vpn. You will need the required isakmp commands, the crypto map and bind it to the outside interface, an access-list bound to the crypto map to determine which traffic is to be encrypted and which traffic not, and more.

Could you please give more detail, cause it to difficult to say what is wrong at your setup. Please provide us with the config of your PIX (but remember to snip out the encrypted passwords and public IP adresses before posting)

I´m sure this will help in answering your question

Kind Regards,

Leo

l4nier · ‎07-17-2003

Hi Sorry for the lack of detail.

I am actually not trying to establish a site to site tunnel. I am behind a pix firewall 515. I have a customer who has a nortel contivity vpn server. They have provided us with a contivity vpn client. I have installed and tried to connect using the ip they gave me for their firewall which is xxx.xxx.xxx.67. However I cannot connect and when I check my logs the only error I see is the one I posted previous showing a udp denied from .69. I am assuming and I may be wrong but I think the pix is looking for a response from the .67 and the pix doens't know what is coming in from the .69 so it is denying it.

The bottom line on what I am trying to do is this. I want to connect to their vpn server and allow traffic back and forth by opening up access to their whole subnet (or maybe just those two ips) to our network.

Honestly I am really out of my element here. I am not quite sure how to go about connecting to them and am looking for any work arounds or solutions to allow my users to vpn into their network.

Any help would be greatly appreciated!!!!

Louanne

lfournier@nexterna.com

jmia · ‎07-18-2003

Hi Louanne,

Can you please provide the config of your PIX, but please remember to change IP's and password/s, If you like you can send it directly to me - email above.

Thanks -

jmia · ‎07-18-2003

Louanne,

Forgot to add the following link for you,

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml

The above link is for PIX-to-PIX config but will help in toubleshooting.

Thanks --

l.mourits · ‎07-18-2003

Hi Louanne,

So, let's see, you have a contivity vpn client, which is behind your PIX firewalls and wants to establishe a secured tunnel to the vpn peer at x.x.x.67

In the logging you are seeing UDP/139 from a system within the same range as this vpn peer (x.x.x.69)

These two do nat have anything in common, as you might think. UDP/139 is Netbios over TCP, which you do not need for establishing your required vpn.

Most likely your PIX is doing so called PAT (Port Address Translation) which you can determine by looking at your PIX config (look for nat and global commands in place). If your PIX does PAT, and you try to connect a vpn tunnel via PAT, the responding peer (which in this case is the contivity vpn server) has to know about the PAT device within the traversal path. This is known as NAT transparancy. Not every VPN peer has this feature, so, you have to ask the guys of the contivity vpn server if their server supports NAT transparancy. Another solution could be permitting UDP port 500 on your PIX from the source address x.x.x.67, but this is not recommended at all.

So, please try to get some information on the coonfig of their vpn server, cause it seems to me that the problem does not reside in your PIX, but within their vpn server.

Kind Regards,

Leo

l4nier · ‎07-18-2003

I agree that the problem is on their end. I connect to many other customers vpns with no problems or if changes need to be made it is usually on their end. The problem that I am faced with is that the "vpn people" on their end are really not vpn people and have no support with Nortel so really can't help me. Normally we would say well you fix it but in this case that won't work. So I have to find a work around to get into their network. I figured it would be something like open udp 500 and protocol 50 but I am just not sure. I am a novice myself and don't want to make any big mistakes on our side.

Louanne

l.mourits · ‎07-18-2003

This sounds like a dead lock situation then, cause you do need the other site guys to help you out :-)

I would not open all kinds of ports on my PIX, because the other site does not have any knowledge of VPN's and the technical issue that come together with IPSec like solutions.

Sorry to say so, but I'm afraid we can't help you in that case :-(

Kind Regards,

Leo

l4nier · ‎07-18-2003

I know this isn't a good solution but it seems like it might be my only solution. I won't leave the ports open but would just open things up while they go in and do their support and then lock it down again. So is there a way to do it even though it isn't the best way to do it?

Louanne

l.mourits · ‎07-18-2003

Okay then Louanne,

On your own risk ofcourse, since you do not know exactly how they want the client vpn to connect, you could open the following on your outside interface:

access-list outside-in permit 50 host

access-list outside-in permit 51 host

access-list outside-in permit udp host eq 500

access-list outside-in permit tcp host eq 10000

Protocol 50 = AH (not commonly used for client to side vpn)

Protocol 51 = ESP (mostly used)

UDP port 500 is mostly used

TCP port 10000 is also frequently used

Difficult thing could be the destination address, if you Port Address translate outside connections to the interface address on the outside this would be the outside interface address, if you have configured a pool of addresses for PAT you would have to add this whole pool in this access-lists

Again, this it NOT recommended at all, you are taking a big risk here, so I would not do it, but this should work I'll guess.....

Kind Regards,

Leo