I have a laptop running the subject VPN Client
I have a PIX 515E running in stateful failover mode with a VAC
I attempted to replace the VAC with a VAC+, and not having a brain in my head on a late Saturday night, I just pulled open the PIX and switched the cards. The remote access users then began to call. I've been working on this problem for a week and am at my wits end. I do keep good notes, and so reconfigured the VPN with exactly the same command set I had used originally with no success.
Here is a copy of the (sanitized) relavent portions of the PIX configuration:
ip address outside 220.127.116.11 255.255.255.X
ip address inside 18.104.22.168 255.255.255.X
#Note: The IP networks for access-list "split" and access-list "nonat_inside" are the same
access-list split permit ip 192.168.XX.0 255.255.255.0 192.168.X1.0 255.255.255.0
access-list nonat_inside permit ip 192.168.XX.0 255.255.255.0 192.168.X1.0 255.255.255.0
Note: Local pool "vpnpool1" includes addresses from the same subnet as configured in the access-lists above
ip local pool vpnpool1 192.168.X1.X-192.168.X1.X
nat (inside) 0 access-list nonat_inside
route outside 0.0.0.0 0.0.0.0 22.214.171.124 1
Many routing statements .......
route inside 192.168.X1.X 255.255.X.X 126.96.36.199 1
More Routing Statements .........
I get good ISAKMP packet trades, good DPD packets, actually a good connection to the VPN from the remote. All indications from the client log are that everything is copasetic. Then I look at the syslog output and see:
%PIX-3-106011: Deny inbound (No xlate) udp src outside:domain-dns/53 dst outside:192.168.X1.X/3554
AAAHHHHH! What am I missing here? Thoughts, suggestions, more info required?
Well, from the looks of the logged message, it gives the appearance as though you have a NAT issue. But I don't think this is the case... The traffic that the log was depicting looks like a return packet for a DNS query from a VPN client to possibly your Internal DNS server - however, according to the log message, the PIX thinks the interface that the DNS server is on is also the outside interface... so there's no defined translation for that, thus the message is logged - a strange log message indeed.
So, is the problem VPN? No... you are clearly encapsulating and decapsulating packets, or else this message would never have appeared.
One thing that jumps out at me in the config you supplied is your route statment:
You defined it as an internal route, but is this not the subnet (or at least part of it) of your VPN address pool? If so, then you need to specify specifically the VPN address pool portion routes to the outside interface... for example, if 192.168.10.0 255.255.255.0 was your VPN address range, and the rest of 192.168.0.0 255.255.0.0 was on the internal network, you should have two routes: