1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

RV042 VPN to PIX 506E - No UDP or ICMP

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by Tempest_Prime, Oct 6, 2006.

  1. Tempest_Prime

    Tempest_Prime LI Guru Member

    I've got a fairly weird situation, and I thought I would post here to see if anyone else ran into a similar problem. Searching the site didn't turn up anything that helped, so here goes...

    I have an environment about to go live where I have a Cisco PIX at the border of a private WAN. In order to reduce cost to the end user, we will be using RV042 routers at a couple of branch offices where providing private network connectivity was either impossible or cost prohibitive. I'd have just used more Cisco firewalls, but cost was an issue.

    Anyhow, I have an RV042 and a PIX 506E set up in a test environment connected to a stub of this private network for isolated testing. We're basically just running a DES/MD5/Group 2 (tried with and without PFS) tunnel between the two units. and live behind the PIX, and lives behind the RV042. I accomplish connection to both subnets by using two different tunnels. I encounter these problems whether I have one tunnel or two. The tunnels seem to connect up just fine. I can establish TCP-based connections such as telnet, but I am not able to process any ICMP or UDP data through the tunnel. The tunnel works just fine when instead of an RV042 we use something like another PIX or a Netopia 3356-ENT. I checked and double checked the access rules and what not, and I don't have anything explicitly blocking the UDP and ICMP traffic. Naturally, everyone involved in the project is a bit concerned because time is starting to run out for us to implement SOMETHING, and we've already purchased 4 RV042s to be sent out to the offices that need them the quickest. I'm not sure if the PIX and the RV042 are deciding to only let TCP through or what, but I do have a sample of some ICMP debug output from the PIX that suggests that the ICMP traffic is coming through the RV042, through the PIX, to the host, and back at least to the PIX again:

    21: ICMP echo-request from outside: to ID=79 seq=52480 length=40
    22: ICMP echo-reply from inside: to ID=79 seq=52480 length=40
    23: ICMP echo-request from outside: to ID=80 seq=52736 length=40
    24: ICMP echo-reply from inside: to ID=80 seq=52736 length=40

    I also tried to have one of the routers inside the private WAN send its config back to me via TFTP. I wasn't really surprised when UDP didn't work either, but I got an interesting message when I checked the PDM log in the PIX:

    Deny inbound (No xlate) udp src inside: dst inside:

    I'm at a complete loss as to why I only see these with the RV042, but that's just how it happens. If anyone has any info that would help me to get this working I'd really appreciate it.


  2. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    I drew a picture of your network, examined it for a bit, then had one observation off the top of my head. (be gentle!) I noticed a few contradictions (namely that ICMP *does* work according to your trace) and thus suggest:

    When you setup the RV042, it only allows you to protect one local network when talking to (again) *one* remote network on the other side of the VPN. I infer from your post that you are trying to protect 2x inside networks on your PIX, the network and the networks.

    When the VPN is negotiated in Phase I, the RV042 and the PIX will only be able to successfully negotiate one-to-one protection between them. For example, the PIX will offer to protect the *and* packets when talking to the network on the RV042, and the RV042 can only offer to protect when talking to *either* or Looking at syslog output while this is being negotiated would be very instructive.

    Continuing (but with the scantiest of evidence), it almost seems like the network is the "winner" since the DA: packet is being "tossed" (witness your syslog output denying inbound because of no xlate). The PIX is saying, "Cool, a packet from to ....oops that can't be VPN traffic because I've negotiated that the inbound traffic from the network is going to my only....better see if I have an existing translation slot for that inbound packet. Darn, there isn't one! Time to toss the packet." This seems to be born out in that your ICMP example between those and networks seems to work but the UDP traffic between and the doesn't. We're comparing apples and oranges.

    Assuming for a moment that you have a router behind your PIX506E and in front of the networks, you could NAT the network to the network on that router and see if the traffic flows both ways.

    Other things to check:

    Make sure that the ACL that you have setup to exempt traffic from NAT on the PIX is properly set up.

    Anyway...let us know what you turn up!

  3. Tempest_Prime

    Tempest_Prime LI Guru Member

    Thanks for your reply, Eric.

    I did state in the body of my message that I have this issue whether I configure one or both of these thunnels. I first encountered the issue with just the tunnel because it was the more critical of the two sets of data I wanted to protect with the VPN. I can actually telnet and establish TCP connections to BOTH subnets simultaneously when both tunnels are up, but I have not been able to pass ANY ICMP or UDP traffic through the unit at all.

    The NONAT ACLs are set up properly. I actually just use the quick n easy 'VPN Wizard' in the PDM to set up the VPN tunnels. This setup works without modification in the PIX if I swap out the RV042 for some other piece of gear such as another PIX or the Netopia DSL router I mentioned earlier. That's what has me so baffled... The basic stuff all seems to be in-line, but I can't get the traffic flowing properly with the RV042... ARRGH! :p
  4. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    Thanks for the clarification. I was having trouble seeing it.

    It does seem odd. Have you tried taking a "Dirty Harry" approach and blow away the config on the RV042 with a hard reset and start over? Also (this is a shameful stretch) have you upgraded the firmware on the RV042 to the latest code? The PIX to version 6.3(5)?

    I searched for your problem on CCO and couldn't find anything similar and didn't expect to.

    I wonder if the VPN wizard forgot to insert the "sysopt connection permit-ipsec" command in your configuration?

    ...just rambling.

  5. Tempest_Prime

    Tempest_Prime LI Guru Member

    I'm gunna blast the RV042 right now. I love blasting stuff, and configs can always be rebuilt!

    RV042 is running the beta firmware. I thought it might help, but it didn't have any noticable effect. Nice new features though. The PIX is running 6.3(5)... I'll let you know what happens when I'm done showing the RV042 my violent side... mwhahahah! :D

    (edit) I forgot to mention that the sysopt thing for ipsec connections is in the PIX config, too.
  6. Tempest_Prime

    Tempest_Prime LI Guru Member

    Restoring the unit to factory defaults didn't make any difference. Oh well, it was definitely worth a shot. I have it set up with only the 172 tunnel this time around... Might as well keep the variables down.
  7. Tempest_Prime

    Tempest_Prime LI Guru Member

    Weird. The forum seems to have eaten our last 3 or 4 messages... Anyhow, this issue is resolved.

Share This Page