Pix 501 Tunnelling problem

Hi, Im not too familiar with pix and vpn tunnels and have run in to a problem.

I've got the following setup

Site X Site Y

(ip 1.1.1.1)--------Internet----------(ip 2.2.2.2) / \\---------VPN-------------/ \\ (Mail server) (Mail server) (ip 1.1.2.2) (private IP 10.0.0.2)

The tunnel allows traffic from the whole 1.1.2.0/24 net of site X to the whole 10.0.0.0/24 net of site Y with NAT exemption.

This works correctly for all applications, exept mail. When the mail server at site X looks up the mx record of site Y it see's the NATed address of 2.2.2.2 and not the real address of

10.0.0.2. So the smtp session is set up over the internet from site X, but when site Y mail server tries to respon the pix sends the traffic through the tunnel to site X and it gets dropped because of asymetrical routing. (wrong source IP).

I do not administer site X and cannot change mx record to the private address and have therefore tried to force traffic from the mail server at site Y to go over the internet as opposed to the tunnel when sending to mail server at site X. But I just cant get it to work.

Hope some of this made any sense and all suggestions would be most appreciated.

-SAto

Reply to
SAto
Loading thread data ...

This sounds like a DNS issue. If you have internal DNS create a zone for the domain and add the internal IP for the mail server or edit the hosts file and manually add the host name of the mail server. You are most likely getting external DNS response for the mail server, this is not a PIX issue but a DNS issue.

chad

Reply to
Chad Mahoney

Chad Mahoney skrev:

That's true but as I stated I have no control of either the mail server at site x nor of their internal DNS server. Putting the private address for the mail server as an mx record on the official DNS server would work but not be a good solution. (And as of now I do not control the official DNS server for that domain either.)

I was wondering if there was a way of exepting this traffic from the tunell and routing it over the internet. There is absolutely no need for any of the mail traffic to go through the tunnell.

-SAto

Reply to
SAto

Ok presumably you have some kind of no-nat access list like this at site Y:-

access-list no-nat permit ip 10.0.0.0 255.255.255.0 1.1.2.0

255.255.255.0

If so, change to this:-

access-list no-nat deny ip host 10.0.0.2 host 1.1.2.2 access-list no-nat permit ip 10.0.0.0 255.255.255.0 1.1.2.0

255.255.255.0

Or maybe a Layer 4 rule so only SMTP from the server is not subjected to NAT:-

access-list no-nat deny tcp host 10.0.0.2 host 1.1.2.2 eq smtp access-list no-nat permit ip 10.0.0.0 255.255.255.0 1.1.2.0

255.255.255.0

You may also need to add the deny rule to your Crypto Access-List otherwise the PIX will still try to send the packets over the VPN.

I haven't been able to test the above as I no longer work on PIX's but I think it should work.

James

Reply to
James

Almost forgot - your Crypto access-lists have to match on each device otherwise you will break the VPN ;-)

James

Reply to
James

James skrev:

This is excatly what I've done, I can se the pix create a nat entry for it in the sh xlate table but the packet never exits the outside interface. I use capture on the outside interface to see traffic. I'm thinking maybe the deny statement in the crypto access list is forcing the pix to drop the packet?

Surprisingly enough editing the crypto map on my side doesn't break the tunnel.

access-list inside_outbound_nat0_acl deny ip host 10.0.0.2 host 1.1.2.2 access-list inside_outbound_nat0_acl permit ip 10.0.0.0 255.255.255.0

1.1.2.0 255.255.255.0 access-list outside_cryptomap_20 deny ip host 10.0.0.2 host 1.1.2.2 access-list outside_cryptomap_20 permit ip 10.0.0.0 255.255.255.0 1.1.2.0 255.255.255.0

Maybe the 10.0.0.0/24 1.1.2.0/24 mapping on both ends match so that the VPN doesnt break, I would expect it to break if I changed it to several smaller subnets to exclude the mail server that way though.

This may not be possible to accomplish at all. Is it possible to put a route map on the incoming interface sending the packet out the outside interface instead? I could create the route map but didn't find a way to put it on the interface. Don't know the correct pix 6.3 syntax.

-SAto

Reply to
SAto

I think I have seen this before, where I used to work we had a case open with Cisco which they could not replicate or resolve.....

The fix was to add a static route for the remote address, however, this is messy:-

route outside 1.1.1.2 255.255.255.0 ipofgateway

Rather than rely on the PIX capture, can you capture traffic between the outside interface and the router?

I have never used the PIX route-map feature so not sure - it's probably there for OSPF route filtering.

James

Reply to
James

Reply to
James

James skrev:

Ive tried that as well but with no success. But I think I just figured out something. The problem is not what I thought it was. It seams that traffic is correctly being sent out the outside interface, but does not get capture by the capture because the outside interface is PPPOE. Sorry about that one!

So the traffic is correctly flowing across the internet, now onto correcting the "correct" problem. Thanks for the help, and sorry to waste your time.

The installation is at a remote location without any technical personell available.

Yes, I think so too.

-SAto

Reply to
SAto

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.