×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

troubleshooting return traffic with 1841+vpn client

Unanswered Question

On 15-Dec-2005 I posted a message entitled "some return traffic not going through vpn tunnel (although not all)". Either the post was overwhelming or considered not worthy of a reply so I will attempt to simplify it in the hopes of getting some feedback.


Basically I am trying to determine why port 25 TCP traffic flows correctly (through the VPN tunnel) from the VPN software client to the SMTP server behind an 1841. However, return traffic from the server to the client does not flow back through the VPN tunnel (it routes back out through the public IP address). Traffic on other ports seems to flow properly back and forth in the tunnel.


It seems like the SMTP server does not know how to route the traffic back through the tunnel to the VPN client so it sends the packets out the default gateway. There are no static routes other than the entry for default outbound traffic:


ip route 0.0.0.0 0.0.0.0 Dialer0


Port mapping and other NAT entries are as follows:


ip nat inside source list 110 interface dialer0 overload

ip nat inside source static tcp 10.0.0.209 25 interface dialer0 25 ! exchange smtp virtual server

ip nat inside source static tcp 10.0.0.209 80 interface dialer0 80 ! exchange owa access

ip nat inside source static tcp 10.0.0.209 443 interface dialer0 443 ! exchange owa access - ssl

ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload ! crypto


The ACL 110 is the following:


access-list 110 deny ip 10.0.0.0 0.0.0.255 10.10.10.0 0.0.0.255 ! no nat for vpn

access-list 110 permit ip 10.0.0.0 0.0.0.255 any

access-list 110 permit ip 10.10.10.0 0.0.0.255 any


The route map looks like this:


route-map SDM_RMAP_1 permit 1

match ip address 110


The interface FastEthernet0/0 is configured like this:


ip address 10.0.0.250 255.255.255.0

ip nat inside

ip tcp adjust-mss 1452

no ip redirects

no ip unreachables

no ip proxy-arp

ip virtual-reassembly

ip route-cache flow

duplex auto

speed auto

no cdp enable

no mop enabled

hold-queue 32 in

hold-queue 100 out


And the interface Dialer0 is like this:


ip address negotiated

ip mtu 1492

ip nat outside

ip inspect my-out-rules out

encapsulation ppp

ip tcp adjust-mss 1452

dialer pool 1

dialer-group 1

ppp authentication chap pap callin

ppp chap hostname ****@****.***

ppp chap password *****

ppp pap sent-username ****@****.*** password *****

crypto map SDM_CMAP_1


Can anyone offer suggestions for troubleshooting this apparent routing problem? Thanks! -Louie

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jackko Wed, 12/21/2005 - 15:11
User Badges:
  • Gold, 750 points or more

interesting.


the server should have no idea about the public ip, as the packet has been decrypted by the router before forwarding to the server.


in other words, from the server point of view, the packet is originated from one of the vpn client pool i.e. 10.10.10.x.

Actions

This Discussion