NATting both ways

Discussion in 'Cisco' started by Mike Gauthier, Jan 15, 2008.

  1. I have a 2811s doing many VPNs to partners and clients. These routers are
    on my "VPN" network off a PIX 525. I use static routes on the PIX to get
    the traffic from my networks to the appropriate router and then down the
    VPN. This has been the setup for years here. It works well and is
    predictable.

    All the VPNs are built using crypto maps. We use a combination of dynamic
    and static NATs (depending on connection direction) to a public address
    range we own specifically for these VPN NATs. Our partners and clients
    also use public address in the VPNs so we never have private range
    conflicts. We are using ip nat inside and ip nat outside on our inside and
    outside identified interfaces.

    Recently, this model broke down. I knew this would eventually show its
    ugly head. We have a client that will access a machine behind our pix over
    the internet from a public source address (let's say 20.20.20.20). We also
    have a machine that needs to access this same address (20.20.20.20) over a
    VPN. As all the routing takes place on the PIX, if I route 20.20.20.20 to
    a VPN router, then the over-the-internet connections no longer work (their
    SYN packet comes over the internet, but my reply SYN-ACK routes to the VPN
    tunnel).

    My solution is to use NAT. Instead of our opening connections to
    20.20.20.20, we would open connections to a private address (let's say
    10.0.0.20) that would route to the VPN router and it would then NAT it to
    20.20.20.20 and send it down the tunnel. So I'd basically have two NATs
    happening on this router. One NAT from my source private to my source
    public and another NAT from my destination private (10.0.0.20) to their
    destination public (20.20.20.20).

    Since I'm using ip nat inside on my inside interface and ip nat outside on
    my outside interface, is this possible? Should I use ip nat outside source
    static command?

    Any help would be greatly appreciated.

    MikeG
    Mike Gauthier, Jan 15, 2008
    #1
    1. Advertising

  2. Mike Gauthier

    S Reese Guest

    On Jan 15, 1:15 pm, Mike Gauthier <> wrote:
    > I have a 2811s doing many VPNs to partners and clients. These routers are
    > on my "VPN" network off a PIX 525. I use static routes on the PIX to get
    > the traffic from my networks to the appropriate router and then down the
    > VPN. This has been the setup for years here. It works well and is
    > predictable.
    >
    > All the VPNs are built using crypto maps. We use a combination of dynamic
    > and static NATs (depending on connection direction) to a public address
    > range we own specifically for these VPN NATs. Our partners and clients
    > also use public address in the VPNs so we never have private range
    > conflicts. We are using ip nat inside and ip nat outside on our inside and
    > outside identified interfaces.
    >
    > Recently, this model broke down. I knew this would eventually show its
    > ugly head. We have a client that will access a machine behind our pix over
    > the internet from a public source address (let's say 20.20.20.20). We also
    > have a machine that needs to access this same address (20.20.20.20) over a
    > VPN. As all the routing takes place on the PIX, if I route 20.20.20.20 to
    > a VPN router, then the over-the-internet connections no longer work (their
    > SYN packet comes over the internet, but my reply SYN-ACK routes to the VPN
    > tunnel).
    >
    > My solution is to use NAT. Instead of our opening connections to
    > 20.20.20.20, we would open connections to a private address (let's say
    > 10.0.0.20) that would route to the VPN router and it would then NAT it to
    > 20.20.20.20 and send it down the tunnel. So I'd basically have two NATs
    > happening on this router. One NAT from my source private to my source
    > public and another NAT from my destination private (10.0.0.20) to their
    > destination public (20.20.20.20).
    >
    > Since I'm using ip nat inside on my inside interface and ip nat outside on
    > my outside interface, is this possible? Should I use ip nat outside source
    > static command?
    >
    > Any help would be greatly appreciated.
    >
    > MikeG


    Here's what I've been try to make work using NAT on the external
    interface. So far the VPN clients have been able to connect but not
    communicate with the internal network(s). This configuration also
    creates a VPN to another router on a remote network. This aspect does
    work.


    !
    ! Last configuration change at 19:31:15 PCTime Tue Jan 15 2008 by
    rsreese
    ! NVRAM config last updated at 18:30:45 PCTime Tue Jan 15 2008 by
    rsreese
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    service password-encryption
    !
    hostname 3725router
    !
    boot-start-marker
    boot-end-marker
    !
    no logging buffered
    enable secret 5 $1$BUZ8$sNjxnHHht1NP3co5Vkj2o0
    !
    aaa new-model
    !
    !
    aaa authentication login default local
    aaa authentication ppp default local
    aaa authorization exec default local
    aaa authorization network default local
    !
    aaa session-id common
    clock timezone PCTime -5
    clock summer-time PCTime date Apr 6 2003 2:00 Oct 26 2003 2:00
    no network-clock-participate slot 1
    no network-clock-participate slot 2
    ip cef
    !
    !
    no ip dhcp use vrf connected
    ip dhcp excluded-address 172.16.2.1
    ip dhcp excluded-address 172.16.3.1
    !
    ip dhcp pool VLAN2clients
    network 172.16.2.0 255.255.255.0
    default-router 172.16.2.1
    dns-server 205.152.144.23 205.152.132.23
    !
    ip dhcp pool VLAN3clients
    network 172.16.3.0 255.255.255.0
    default-router 172.16.3.1
    dns-server 205.152.144.23 205.152.132.23
    !
    !
    ip domain name neocipher.net
    ip name-server 205.152.144.23
    ip name-server 205.152.132.23
    ip auth-proxy max-nodata-conns 3
    ip admission max-nodata-conns 3
    vpdn enable
    !
    vpdn-group 1
    ! Default L2TP VPDN group
    accept-dialin
    protocol l2tp
    virtual-template 1
    no l2tp tunnel authentication
    ip pmtu
    !
    vpdn-group L2TP_VPN
    accept-dialin
    protocol l2tp
    virtual-template 1
    no l2tp tunnel authentication
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    crypto pki trustpoint TP-self-signed-995375956
    enrollment selfsigned
    subject-name cn=IOS-Self-Signed-Certificate-995375956
    revocation-check none
    rsakeypair TP-self-signed-995375956
    !
    !
    crypto pki certificate chain TP-self-signed-995375956
    certificate self-signed 01
    3082024E 308201B7 A0030201 02020101 300D0609 2A864886 F70D0101
    04050030
    30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D
    43657274
    69666963 6174652D 39393533 37353935 36301E17 0D303230 33303130
    36313133
    335A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403
    1325494F
    532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3939
    35333735
    39353630 819F300D 06092A86 4886F70D 01010105 0003818D 00308189
    02818100
    CF80B9FF 105E6689 8ECB41A9 A433EA68 9142AC1C 27941675 D8308151
    4C68D1E8
    A13039C9 75CBB9B3 C5078A7B FF67D8C0 FC1EBBF8 0C17EE00 BCA4056E
    1903F769
    0C21CAB6 D04CCAAA 73D4F744 523FE2B1 0E2AC55C F85A6896 347328B1
    504B8A05
    FAA9C1DF 31786DA6 3F64652C 9AE3B1C5 5E69122C 748160E3 818F110F
    3978F0FF
    02030100 01A37830 76300F06 03551D13 0101FF04 05300301 01FF3023
    0603551D
    11041C30 1A821833 37323572 6F757465 722E6E65 6F636970 6865722E
    6E657430
    1F060355 1D230418 30168014 FC48BF7D 9B97167A 41CF22FD 013C798A
    154EC666
    301D0603 551D0E04 160414FC 48BF7D9B 97167A41 CF22FD01 3C798A15
    4EC66630
    0D06092A 864886F7 0D010104 05000381 8100CA4B 1A56F508 476C297C
    32C830F2
    21EBA101 A3D47202 7DD7FCB8 E91911EF 6EFC8095 0AA1B548 14468A43
    41A8E271
    176CC0F1 C576F65F 125A2A64 785149D9 1A302553 37E59C30 B59CEF3D
    C63E5019
    8897B79D C3DA4587 5EF1BC45 B10CB03C 0BFC1E1F 0AF2DF66 16653E18
    5E2FC795
    5D9BB821 85471E48 C34845A2 1BE83EAF F58D
    quit
    username rsreese privilege 15 secret 5 $1$k.mV$065vhIx6xkX.kM6jxTAOM.
    !
    !
    ip ssh authentication-retries 2
    !
    !
    crypto isakmp policy 3
    encr 3des
    authentication pre-share
    group 2
    !
    crypto isakmp policy 10
    hash md5
    authentication pre-share
    crypto isakmp key cisco address 10.0.0.2 no-xauth
    !
    crypto isakmp client configuration group VPN-Users
    key test00
    dns 205.152.144.23 205.152.132.23
    domain neocipher.net
    pool VPN_POOL
    include-local-lan
    max-logins 1
    netmask 255.255.255.0
    !
    !
    crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
    !
    crypto dynamic-map DYNMAP 10
    set transform-set ESP-3DES-SHA
    !
    !
    crypto map CLIENTMAP client authentication list default
    crypto map CLIENTMAP isakmp authorization list default
    crypto map CLIENTMAP client configuration address respond
    crypto map CLIENTMAP 1 ipsec-isakmp
    set peer 10.0.0.2
    set transform-set ESP-3DES-SHA
    match address 100
    crypto map CLIENTMAP 10 ipsec-isakmp dynamic DYNMAP
    !
    !
    !
    !
    interface Loopback0
    ip address 1.1.1.1 255.255.255.0
    !
    interface FastEthernet0/0
    ip address dhcp client-id FastEthernet0/0 hostname 3725router
    ip nat outside
    ip virtual-reassembly
    speed 100
    full-duplex
    crypto map CLIENTMAP
    !
    interface Serial0/0
    ip address 10.0.0.1 255.255.240.0
    clock rate 2000000
    crypto map CLIENTMAP
    !
    interface FastEthernet0/1
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/1.2
    encapsulation dot1Q 2
    ip address 172.16.2.1 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    crypto map CLIENTMAP
    !
    interface FastEthernet0/1.3
    encapsulation dot1Q 3
    ip address 172.16.3.1 255.255.255.0
    ip virtual-reassembly
    !
    interface Serial0/1
    no ip address
    shutdown
    clock rate 2000000
    !
    interface Virtual-Template1
    ip unnumbered FastEthernet0/0
    peer default ip address pool PPTP-POOL
    no keepalive
    ppp encrypt mppe auto required
    ppp authentication pap chap ms-chap
    !
    ip local pool PPTP-POOL 172.16.20.25 172.16.20.35
    ip local pool VPN_POOL 192.168.0.55 192.168.0.105
    ip default-gateway 192.168.1.1
    ip forward-protocol nd
    ip route 0.0.0.0 0.0.0.0 192.168.1.1
    ip route 172.16.10.0 255.255.255.0 10.0.0.2
    ip route 192.168.0.0 255.255.255.0 192.168.1.1
    !
    !
    no ip http server
    ip http authentication local
    ip http secure-server
    ip http timeout-policy idle 600 life 86400 requests 10000
    ip nat inside source list 111 interface FastEthernet0/0 overload
    !
    access-list 100 permit ip 172.16.2.0 0.0.0.255 172.16.10.0 0.0.0.255
    access-list 111 permit ip 172.16.0.0 0.0.255.255 any
    access-list 120 permit ip 192.168.0.0 0.0.0.255 any
    !
    !
    !
    !
    control-plane
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    line con 0
    line aux 0
    line vty 0 4
    password 7 05080F1C2243
    transport input ssh
    line vty 5 903
    transport input ssh
    !
    ntp clock-period 17180664
    ntp server 129.6.15.29 source FastEthernet0/0 prefer
    !
    end
    S Reese, Jan 16, 2008
    #2
    1. Advertising

  3. Mike Gauthier

    Guest

    On Jan 15, 10:15 am, Mike Gauthier <> wrote:
    > I have a 2811s doing many VPNs to partners and clients. These routers are
    > on my "VPN" network off a PIX 525. I use static routes on the PIX to get
    > the traffic from my networks to the appropriate router and then down the
    > VPN. This has been the setup for years here. It works well and is
    > predictable.
    >
    > All the VPNs are built using crypto maps. We use a combination of dynamic
    > and static NATs (depending on connection direction) to a public address
    > range we own specifically for these VPN NATs. Our partners and clients
    > also use public address in the VPNs so we never have private range
    > conflicts. We are using ip nat inside and ip nat outside on our inside and
    > outside identified interfaces.
    >
    > Recently, this model broke down. I knew this would eventually show its
    > ugly head. We have a client that will access a machine behind our pix over
    > the internet from a public source address (let's say 20.20.20.20). We also
    > have a machine that needs to access this same address (20.20.20.20) over a
    > VPN. As all the routing takes place on the PIX, if I route 20.20.20.20 to
    > a VPN router, then the over-the-internet connections no longer work (their
    > SYN packet comes over the internet, but my reply SYN-ACK routes to the VPN
    > tunnel).
    >
    > My solution is to use NAT. Instead of our opening connections to
    > 20.20.20.20, we would open connections to a private address (let's say
    > 10.0.0.20) that would route to the VPN router and it would then NAT it to
    > 20.20.20.20 and send it down the tunnel. So I'd basically have two NATs
    > happening on this router. One NAT from my source private to my source
    > public and another NAT from my destination private (10.0.0.20) to their
    > destination public (20.20.20.20).
    >
    > Since I'm using ip nat inside on my inside interface and ip nat outside on
    > my outside interface, is this possible? Should I use ip nat outside source
    > static command?
    >
    > Any help would be greatly appreciated.
    >
    > MikeG


    Mike,

    If I understand you correctly, this shouldn't be a problem; but you
    need to make sure that the 20.20.20.20 machine knows to send reply
    packets to the target host through the VPN tunnel instead of the
    Internet. You should only need to use the 'ip nat outside source
    static' command if the 20.20.20.20 is initiating a connection to your
    inside host through the VPN tunnel.

    neteng
    http://blog.humanmodem.com
    , Jan 16, 2008
    #3
  4. On Wed, 16 Jan 2008 10:06:40 -0800, wrote:

    > On Jan 15, 10:15 am, Mike Gauthier <> wrote:
    >> I have a 2811s doing many VPNs to partners and clients. These routers
    >> are on my "VPN" network off a PIX 525. I use static routes on the PIX
    >> to get the traffic from my networks to the appropriate router and then
    >> down the VPN. This has been the setup for years here. It works well and
    >> is predictable.
    >>
    >> All the VPNs are built using crypto maps. We use a combination of
    >> dynamic and static NATs (depending on connection direction) to a public
    >> address range we own specifically for these VPN NATs. Our partners and
    >> clients also use public address in the VPNs so we never have private
    >> range conflicts. We are using ip nat inside and ip nat outside on our
    >> inside and outside identified interfaces.
    >>
    >> Recently, this model broke down. I knew this would eventually show its
    >> ugly head. We have a client that will access a machine behind our pix
    >> over the internet from a public source address (let's say 20.20.20.20).
    >> We also have a machine that needs to access this same address
    >> (20.20.20.20) over a VPN. As all the routing takes place on the PIX, if
    >> I route 20.20.20.20 to a VPN router, then the over-the-internet
    >> connections no longer work (their SYN packet comes over the internet,
    >> but my reply SYN-ACK routes to the VPN tunnel).
    >>
    >> My solution is to use NAT. Instead of our opening connections to
    >> 20.20.20.20, we would open connections to a private address (let's say
    >> 10.0.0.20) that would route to the VPN router and it would then NAT it
    >> to 20.20.20.20 and send it down the tunnel. So I'd basically have two
    >> NATs happening on this router. One NAT from my source private to my
    >> source public and another NAT from my destination private (10.0.0.20)
    >> to their destination public (20.20.20.20).
    >>
    >> Since I'm using ip nat inside on my inside interface and ip nat outside
    >> on my outside interface, is this possible? Should I use ip nat outside
    >> source static command?
    >>
    >> Any help would be greatly appreciated.
    >>
    >> MikeG

    >
    > Mike,
    >
    > If I understand you correctly, this shouldn't be a problem; but you need
    > to make sure that the 20.20.20.20 machine knows to send reply packets to
    > the target host through the VPN tunnel instead of the Internet. You
    > should only need to use the 'ip nat outside source static' command if
    > the 20.20.20.20 is initiating a connection to your inside host through
    > the VPN tunnel.
    >
    > neteng
    > http://blog.humanmodem.com


    They know what to route down the VPN, but we're initiating a connections
    to 20.20.20.20. Will the 'ip nat outside source static' command still
    work?

    MikeG
    Mike Gauthier, Jan 17, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. manu
    Replies:
    0
    Views:
    472
  2. xcelloM

    Natting with cisco 803

    xcelloM, Nov 3, 2004, in forum: Cisco
    Replies:
    1
    Views:
    822
    Martin Bilgrav
    Nov 4, 2004
  3. Cisco

    Natting question

    Cisco, Dec 2, 2004, in forum: Cisco
    Replies:
    4
    Views:
    1,633
  4. Raymond Doetjes

    PIX natting of a VPN tunnel?

    Raymond Doetjes, Dec 20, 2004, in forum: Cisco
    Replies:
    2
    Views:
    1,399
    Walter Roberson
    Dec 20, 2004
  5. b
    Replies:
    9
    Views:
    1,104
    Plato
    Apr 21, 2006
Loading...

Share This Page