Having trouble with internal users accessing the Internet using NAT

Discussion in 'Cisco' started by novatech1989@yahoo.com, Jan 22, 2007.

  1. Guest

    I am having issues where some of my users are not getting out to the
    Internet. I have narrowed it down (I believe) to my nat statements.
    Some users ip's are not being translated to our outgoing IP. The
    following is my config file. It includes statements for our VPN and
    mail server access (which are working):

    PIX Version 6.3(4)
    interface ethernet0 10baset
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password xuEY8/rL5zQAjHOY encrypted
    passwd 2KFQnbNIdI.2KYOU encrypted
    hostname firewall
    domain-name ciscopix.com
    fixup protocol dns maximum-length 512
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol ils 389
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    fixup protocol tftp 69
    names
    object-group service outbound-blocked-ports tcp-udp
    port-object eq 389
    port-object eq 69
    port-object eq 445
    port-object range 135 139
    access-list inbound permit icmp any any
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq www
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq smtp
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq 3389
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq https
    access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0
    255.255.255.0
    access-list outbound deny tcp any any object-group
    outbound-blocked-ports
    access-list outbound deny udp any any object-group
    outbound-blocked-ports
    access-list outbound permit ip any any
    access-list outbound permit ip 192.168.1.0 255.255.255.0 10.1.1.0
    255.255.255.0
    access-list outside_crytomap_dyn_20 permit ip any 192.168.1.0
    255.255.255.128
    pager lines 20
    mtu outside 1500
    mtu inside 1500
    ip address outside 65.xxx.xxx.125 255.255.255.248
    ip address inside 192.168.1.254 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool vpnpool1 10.1.1.1-10.1.1.50
    pdm location 192.168.1.0 255.255.255.128 outside
    pdm location 65.xxx.xxx.122 255.255.255.255 outside
    pdm location 10.1.1.0 255.255.255.0 outside
    pdm location 192.168.1.2 255.255.255.255 inside
    pdm logging informational 100
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask
    255.255.255.255 0 0
    access-group inbound in interface outside
    access-group outbound in interface inside
    conduit permit icmp any any
    route outside 0.0.0.0 0.0.0.0 65.xxx.xxx.121 1
    timeout xlate 3:00:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
    1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server RADIUS (inside) host 192.168.1.2 quality timeout 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.1.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-ipsec
    sysopt connection permit-pptp
    sysopt connection permit-l2tp
    crypto ipsec transform-set TRANS_ESP_3DES_SHA esp-3des esp-sha-hmac
    crypto ipsec transform-set TRANS_ESP_3DES_SHA mode transport
    crypto dynamic-map outside_dyn_map 20 match address
    outside_crytomap_dyn_20
    crypto dynamic-map outside_dyn_map 20 set transform-set
    TRANS_ESP_3DES_SHA
    crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
    crypto map outside_map interface outside
    isakmp enable outside
    isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
    isakmp policy 20 authentication pre-share
    isakmp policy 20 encryption 3des
    isakmp policy 20 hash sha
    isakmp policy 20 group 2
    isakmp policy 20 lifetime 86400
    telnet 192.168.1.0 255.255.255.0 inside
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    vpdn group L2TP-VPDN-GROUP accept dialin l2tp
    vpdn group L2TP-VPDN-GROUP ppp authentication pap
    vpdn group L2TP-VPDN-GROUP ppp authentication chap
    vpdn group L2TP-VPDN-GROUP ppp authentication mschap
    vpdn group L2TP-VPDN-GROUP client configuration address local vpnpool1
    vpdn group L2TP-VPDN-GROUP client configuration dns 192.168.1.2
    vpdn group L2TP-VPDN-GROUP client configuration wins 192.168.1.2
    vpdn group L2TP-VPDN-GROUP client authentication local
    vpdn group L2TP-VPDN-GROUP l2tp tunnel hello 60
    vpdn group PPTP-VPDN-GROUP accept dialin pptp
    vpdn group PPTP-VPDN-GROUP ppp authentication pap
    vpdn group PPTP-VPDN-GROUP ppp authentication chap
    vpdn group PPTP-VPDN-GROUP ppp authentication mschap
    vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
    vpdn group PPTP-VPDN-GROUP client configuration address local vpnpool1
    vpdn group PPTP-VPDN-GROUP client configuration dns 192.168.1.2
    vpdn group PPTP-VPDN-GROUP client configuration wins 192.168.1.2
    vpdn group PPTP-VPDN-GROUP pptp echo 60
    vpdn group PPTP-VPDN-GROUP client authentication local
    vpdn username myuser password *********
    vpdn enable outside
    terminal width 80
    Cryptochecksum:89db6a16929992045353d2f5bfa29044
    : end
    , Jan 22, 2007
    #1
    1. Advertising

  2. In article <>,
    <> wrote:
    >I am having issues where some of my users are not getting out to the
    >Internet. I have narrowed it down (I believe) to my nat statements.
    >Some users ip's are not being translated to our outgoing IP.


    Is it perhaps a PIX 501 that is reaching its license limits?

    >The
    >following is my config file. It includes statements for our VPN and
    >mail server access (which are working):


    The parts of your configuration that look broken to me are those
    dealing with your VPN. You do not have a nat 0 access-list statement,
    or an equivilent static, so traffic going out to your VPN clients
    is going to be NAT'd, and because the source will then be your
    outside interface IP, the traffic is not going to match the
    ACL you have set up for your crypto dynamic map.


    >PIX Version 6.3(4)


    6.3(5)112 has some security fixes that are advised.

    >interface ethernet0 10baset
    >interface ethernet1 100full


    It is the speed and duplex settings that most lead me to suspect PIX 501.


    >access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0


    That access-list appears to be unused.

    >access-list outbound deny tcp any any object-group outbound-blocked-ports
    >access-list outbound deny udp any any object-group outbound-blocked-ports
    >access-list outbound permit ip any any
    >access-list outbound permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0


    permit ip any any is going to include everything specified on the
    next statement, so that fourth ACL line appears to be redundant (but
    that's not going to hurt anything.)

    >access-list outside_crytomap_dyn_20 permit ip any 192.168.1.0 255.255.255.128


    That's the one that won't match after your VPN clients are NAT'd.

    >ip address inside 192.168.1.254 255.255.255.0
    >ip local pool vpnpool1 10.1.1.1-10.1.1.50


    >pdm location 192.168.1.0 255.255.255.128 outside


    That must be a hold-over from a previous configuration. It declares
    that, as far as the PDM is concerned, the first half of 192.168.1.0 is
    "outside" -- but the entire 192.168.1.0 is inside according to your
    ip address statements.

    >pdm location 65.xxx.xxx.122 255.255.255.255 outside
    >pdm location 10.1.1.0 255.255.255.0 outside
    >pdm location 192.168.1.2 255.255.255.255 inside


    >global (outside) 1 interface
    >nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    >static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask 255.255.255.255 0 0
    >access-group inbound in interface outside
    >access-group outbound in interface inside


    Those nat/static/global statements are okay for inside hosts going out,
    but not for your VPN users.

    >conduit permit icmp any any


    conduit and ACLs together can produce unpredictable behaviour. You
    should get rid of the conduit. And consider: do you really want random
    people on the internet to be able to redirect your internal users
    to the attackers phishing site instead of where the users thought they
    were going?? If not then you don't want to permit icmp any, as icmp any
    includes "network redirection".
    Walter Roberson, Jan 22, 2007
    #2
    1. Advertising

  3. Guest

    Thank you for your reply, I will make the changes and see what happens.


    Walter Roberson wrote:
    > In article <>,
    > <> wrote:
    > >I am having issues where some of my users are not getting out to the
    > >Internet. I have narrowed it down (I believe) to my nat statements.
    > >Some users ip's are not being translated to our outgoing IP.

    >
    > Is it perhaps a PIX 501 that is reaching its license limits?
    >
    > >The
    > >following is my config file. It includes statements for our VPN and
    > >mail server access (which are working):

    >
    > The parts of your configuration that look broken to me are those
    > dealing with your VPN. You do not have a nat 0 access-list statement,
    > or an equivilent static, so traffic going out to your VPN clients
    > is going to be NAT'd, and because the source will then be your
    > outside interface IP, the traffic is not going to match the
    > ACL you have set up for your crypto dynamic map.
    >
    >
    > >PIX Version 6.3(4)

    >
    > 6.3(5)112 has some security fixes that are advised.
    >
    > >interface ethernet0 10baset
    > >interface ethernet1 100full

    >
    > It is the speed and duplex settings that most lead me to suspect PIX 501.
    >
    >
    > >access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    >
    > That access-list appears to be unused.
    >
    > >access-list outbound deny tcp any any object-group outbound-blocked-ports
    > >access-list outbound deny udp any any object-group outbound-blocked-ports
    > >access-list outbound permit ip any any
    > >access-list outbound permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    >
    > permit ip any any is going to include everything specified on the
    > next statement, so that fourth ACL line appears to be redundant (but
    > that's not going to hurt anything.)
    >
    > >access-list outside_crytomap_dyn_20 permit ip any 192.168.1.0 255.255.255.128

    >
    > That's the one that won't match after your VPN clients are NAT'd.
    >
    > >ip address inside 192.168.1.254 255.255.255.0
    > >ip local pool vpnpool1 10.1.1.1-10.1.1.50

    >
    > >pdm location 192.168.1.0 255.255.255.128 outside

    >
    > That must be a hold-over from a previous configuration. It declares
    > that, as far as the PDM is concerned, the first half of 192.168.1.0 is
    > "outside" -- but the entire 192.168.1.0 is inside according to your
    > ip address statements.
    >
    > >pdm location 65.xxx.xxx.122 255.255.255.255 outside
    > >pdm location 10.1.1.0 255.255.255.0 outside
    > >pdm location 192.168.1.2 255.255.255.255 inside

    >
    > >global (outside) 1 interface
    > >nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    > >static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask 255.255.255.255 0 0
    > >access-group inbound in interface outside
    > >access-group outbound in interface inside

    >
    > Those nat/static/global statements are okay for inside hosts going out,
    > but not for your VPN users.
    >
    > >conduit permit icmp any any

    >
    > conduit and ACLs together can produce unpredictable behaviour. You
    > should get rid of the conduit. And consider: do you really want random
    > people on the internet to be able to redirect your internal users
    > to the attackers phishing site instead of where the users thought they
    > were going?? If not then you don't want to permit icmp any, as icmp any
    > includes "network redirection".
    , Jan 23, 2007
    #3
  4. Guest

    Thank you for your help. I have made the following changes to the
    script. I am still having problems with users not being able to get
    onto the Internet. If I reboot the Cisco PIX the users can get on with
    no problem. If they are idle for a period of time, like overnight. They
    cannot get on the next morning. I have no idea why the NAT translations
    seem to stop. Here is the new code:


    PIX Version 6.3(4)
    interface ethernet0 10baset
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password xuEY8/rL5zQAjHOY encrypted
    passwd xuEY8/rL5zQAjHOY encrypted
    hostname qualfirewall
    domain-name ciscopix.com
    fixup protocol dns maximum-length 512
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    fixup protocol tftp 69
    names
    object-group service outbound-blocked-ports tcp-udp
    port-object eq 389
    port-object eq 69
    port-object eq 445
    port-object range 135 139
    access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0
    255.255.255.0
    access-list inbound permit tcp any host 65.117.164.122 eq www
    access-list inbound permit tcp any host 65.117.164.122 eq 3389
    access-list inbound permit tcp any host 65.117.164.122 eq smtp
    access-list inbound permit icmp any any
    access-list inbound permit tcp any host 65.117.164.122 eq https
    access-list inside_access_in permit ip 192.168.1.0 255.255.255.0
    10.1.1.0 255.255.255.0
    access-list inside_access_in deny tcp any any object-group
    outbound-blocked-ports
    access-list inside_access_in deny udp any any object-group
    outbound-blocked-ports
    access-list inside_access_in permit ip any any
    pager lines 22
    mtu outside 1500
    mtu inside 1500
    ip address outside 65.117.164.125 255.255.255.248
    ip address inside 192.168.1.254 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool pptp-pool 10.1.1.1-10.1.1.50
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 0 access-list 101
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    static (inside,outside) 65.117.164.122 192.168.1.2 netmask
    255.255.255.255 0 0
    access-group inbound in interface outside
    access-group inside_access_in in interface inside
    route outside 0.0.0.0 0.0.0.0 65.117.164.121 1
    timeout xlate 3:00:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
    1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.1.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-pptp
    telnet 192.168.1.0 255.255.255.0 inside
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    vpdn group 1 accept dialin pptp
    vpdn group 1 ppp authentication pap
    vpdn group 1 ppp authentication chap
    vpdn group 1 ppp authentication mschap
    vpdn group 1 ppp encryption mppe auto
    vpdn group 1 client configuration address local pptp-pool
    vpdn group 1 client configuration dns 192.168.1.2
    vpdn group 1 client configuration wins 192.168.1.2
    vpdn group 1 pptp echo 60
    vpdn group 1 client authentication local
    vpdn username myuser password ********
    vpdn enable outside
    terminal width 80
    Cryptochecksum:1da07a5727608c969af9200

    Walter Roberson wrote:
    > In article <>,
    > <> wrote:
    > >I am having issues where some of my users are not getting out to the
    > >Internet. I have narrowed it down (I believe) to my nat statements.
    > >Some users ip's are not being translated to our outgoing IP.

    >
    > Is it perhaps a PIX 501 that is reaching its license limits?
    >
    > >The
    > >following is my config file. It includes statements for our VPN and
    > >mail server access (which are working):

    >
    > The parts of your configuration that look broken to me are those
    > dealing with your VPN. You do not have a nat 0 access-list statement,
    > or an equivilent static, so traffic going out to your VPN clients
    > is going to be NAT'd, and because the source will then be your
    > outside interface IP, the traffic is not going to match the
    > ACL you have set up for your crypto dynamic map.
    >
    >
    > >PIX Version 6.3(4)

    >
    > 6.3(5)112 has some security fixes that are advised.
    >
    > >interface ethernet0 10baset
    > >interface ethernet1 100full

    >
    > It is the speed and duplex settings that most lead me to suspect PIX 501.
    >
    >
    > >access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    >
    > That access-list appears to be unused.
    >
    > >access-list outbound deny tcp any any object-group outbound-blocked-ports
    > >access-list outbound deny udp any any object-group outbound-blocked-ports
    > >access-list outbound permit ip any any
    > >access-list outbound permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    >
    > permit ip any any is going to include everything specified on the
    > next statement, so that fourth ACL line appears to be redundant (but
    > that's not going to hurt anything.)
    >
    > >access-list outside_crytomap_dyn_20 permit ip any 192.168.1.0 255.255.255.128

    >
    > That's the one that won't match after your VPN clients are NAT'd.
    >
    > >ip address inside 192.168.1.254 255.255.255.0
    > >ip local pool vpnpool1 10.1.1.1-10.1.1.50

    >
    > >pdm location 192.168.1.0 255.255.255.128 outside

    >
    > That must be a hold-over from a previous configuration. It declares
    > that, as far as the PDM is concerned, the first half of 192.168.1.0 is
    > "outside" -- but the entire 192.168.1.0 is inside according to your
    > ip address statements.
    >
    > >pdm location 65.xxx.xxx.122 255.255.255.255 outside
    > >pdm location 10.1.1.0 255.255.255.0 outside
    > >pdm location 192.168.1.2 255.255.255.255 inside

    >
    > >global (outside) 1 interface
    > >nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    > >static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask 255.255.255.255 0 0
    > >access-group inbound in interface outside
    > >access-group outbound in interface inside

    >
    > Those nat/static/global statements are okay for inside hosts going out,
    > but not for your VPN users.
    >
    > >conduit permit icmp any any

    >
    > conduit and ACLs together can produce unpredictable behaviour. You
    > should get rid of the conduit. And consider: do you really want random
    > people on the internet to be able to redirect your internal users
    > to the attackers phishing site instead of where the users thought they
    > were going?? If not then you don't want to permit icmp any, as icmp any
    > includes "network redirection".
    , Jan 23, 2007
    #4
  5. Guest

    Thank you for your help. I have made the following changes to the
    script. I am still having problems with users not being able to get
    onto the Internet. If I reboot the Cisco PIX the users can get on with
    no problem. If they are idle for a period of time, like overnight. They
    cannot get on the next morning. I have no idea why the NAT translations
    seem to stop. Here is the new code:


    PIX Version 6.3(4)
    interface ethernet0 10baset
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password xuEY8/rL5zQAjHOY encrypted
    passwd xuEY8/rL5zQAjHOY encrypted
    hostname qualfirewall
    domain-name ciscopix.com
    fixup protocol dns maximum-length 512
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    fixup protocol tftp 69
    names
    object-group service outbound-blocked-ports tcp-udp
    port-object eq 389
    port-object eq 69
    port-object eq 445
    port-object range 135 139
    access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0
    255.255.255.0
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq www
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq 3389
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq smtp
    access-list inbound permit icmp any any
    access-list inbound permit tcp any host 65.xxx.xxx.122 eq https
    access-list inside_access_in permit ip 192.168.1.0 255.255.255.0
    10.1.1.0 255.255.255.0
    access-list inside_access_in deny tcp any any object-group
    outbound-blocked-ports
    access-list inside_access_in deny udp any any object-group
    outbound-blocked-ports
    access-list inside_access_in permit ip any any
    pager lines 22
    mtu outside 1500
    mtu inside 1500
    ip address outside 65.xxx.xxx.125 255.255.255.248
    ip address inside 192.168.1.254 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool pptp-pool 10.1.1.1-10.1.1.50
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 0 access-list 101
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask
    255.255.255.255 0 0
    access-group inbound in interface outside
    access-group inside_access_in in interface inside
    route outside 0.0.0.0 0.0.0.0 65.xxx.xxx.121 1
    timeout xlate 3:00:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
    1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.1.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-pptp
    telnet 192.168.1.0 255.255.255.0 inside
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    vpdn group 1 accept dialin pptp
    vpdn group 1 ppp authentication pap
    vpdn group 1 ppp authentication chap
    vpdn group 1 ppp authentication mschap
    vpdn group 1 ppp encryption mppe auto
    vpdn group 1 client configuration address local pptp-pool
    vpdn group 1 client configuration dns 192.168.1.2
    vpdn group 1 client configuration wins 192.168.1.2
    vpdn group 1 pptp echo 60
    vpdn group 1 client authentication local
    vpdn username myuser password ********
    vpdn enable outside
    terminal width 80
    Cryptochecksum:1da07a5727608c969af9200

    wrote:
    > Thank you for your reply, I will make the changes and see what happens.
    >
    >
    > Walter Roberson wrote:
    > > In article <>,
    > > <> wrote:
    > > >I am having issues where some of my users are not getting out to the
    > > >Internet. I have narrowed it down (I believe) to my nat statements.
    > > >Some users ip's are not being translated to our outgoing IP.

    > >
    > > Is it perhaps a PIX 501 that is reaching its license limits?
    > >
    > > >The
    > > >following is my config file. It includes statements for our VPN and
    > > >mail server access (which are working):

    > >
    > > The parts of your configuration that look broken to me are those
    > > dealing with your VPN. You do not have a nat 0 access-list statement,
    > > or an equivilent static, so traffic going out to your VPN clients
    > > is going to be NAT'd, and because the source will then be your
    > > outside interface IP, the traffic is not going to match the
    > > ACL you have set up for your crypto dynamic map.
    > >
    > >
    > > >PIX Version 6.3(4)

    > >
    > > 6.3(5)112 has some security fixes that are advised.
    > >
    > > >interface ethernet0 10baset
    > > >interface ethernet1 100full

    > >
    > > It is the speed and duplex settings that most lead me to suspect PIX 501.
    > >
    > >
    > > >access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    > >
    > > That access-list appears to be unused.
    > >
    > > >access-list outbound deny tcp any any object-group outbound-blocked-ports
    > > >access-list outbound deny udp any any object-group outbound-blocked-ports
    > > >access-list outbound permit ip any any
    > > >access-list outbound permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

    > >
    > > permit ip any any is going to include everything specified on the
    > > next statement, so that fourth ACL line appears to be redundant (but
    > > that's not going to hurt anything.)
    > >
    > > >access-list outside_crytomap_dyn_20 permit ip any 192.168.1.0 255.255.255.128

    > >
    > > That's the one that won't match after your VPN clients are NAT'd.
    > >
    > > >ip address inside 192.168.1.254 255.255.255.0
    > > >ip local pool vpnpool1 10.1.1.1-10.1.1.50

    > >
    > > >pdm location 192.168.1.0 255.255.255.128 outside

    > >
    > > That must be a hold-over from a previous configuration. It declares
    > > that, as far as the PDM is concerned, the first half of 192.168.1.0 is
    > > "outside" -- but the entire 192.168.1.0 is inside according to your
    > > ip address statements.
    > >
    > > >pdm location 65.xxx.xxx.122 255.255.255.255 outside
    > > >pdm location 10.1.1.0 255.255.255.0 outside
    > > >pdm location 192.168.1.2 255.255.255.255 inside

    > >
    > > >global (outside) 1 interface
    > > >nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    > > >static (inside,outside) 65.xxx.xxx.122 192.168.1.2 netmask 255.255.255.255 0 0
    > > >access-group inbound in interface outside
    > > >access-group outbound in interface inside

    > >
    > > Those nat/static/global statements are okay for inside hosts going out,
    > > but not for your VPN users.
    > >
    > > >conduit permit icmp any any

    > >
    > > conduit and ACLs together can produce unpredictable behaviour. You
    > > should get rid of the conduit. And consider: do you really want random
    > > people on the internet to be able to redirect your internal users
    > > to the attackers phishing site instead of where the users thought they
    > > were going?? If not then you don't want to permit icmp any, as icmp any
    > > includes "network redirection".
    , Jan 23, 2007
    #5
    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. Mike

    internal to internal NAT?

    Mike, Apr 19, 2004, in forum: Cisco
    Replies:
    1
    Views:
    674
  2. GeekMarine1972
    Replies:
    1
    Views:
    1,265
    Walter Roberson
    Jan 15, 2005
  3. djskyler
    Replies:
    3
    Views:
    552
  4. RobMac
    Replies:
    2
    Views:
    493
    RobMac
    Jan 2, 2007
  5. ishariff
    Replies:
    0
    Views:
    390
    ishariff
    May 19, 2008
Loading...

Share This Page