«

Hi all,

I got a basic Cisco knowledge but a good networking knowledge and I just
ran into somehting I simply can't explain.

My customer contacted me, telling me that he couldn't reach his webserver
anymore.

I figured that something was wrong with PAT to port 443.

I looked at the router for the first time, and couldn't find any (!) NAT
or PAT related command.

Still the clients were able to surf the net. In between the router and the
clients is also a PIX that does a VPN to another office, so I figured that
the NAT was happening on that side, but now the customer tells me that
they are still able to surf when the VPN is down !!!

I attached the config of the Cisco and the PIX located at the first site.

Can anyone make any sence of this ?!? How is the NAT happening?


thx a mille!

B.

Current configuration : 1354 bytes
!
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname CD-VENLO
!
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
clock timezone GMT 1
clock summer-time GMT date Mar 30 2002 1:00 Oct 26 2035 1:59
ip subnet-zero
no ip domain-lookup
!
!
!
!
interface Ethernet0
*ip address 10.25.1.73 255.255.255.248
no ip route-cache
*no keepalive
*no cdp enable
*hold-queue 32 in
*hold-queue 100 out
!
interface ATM0
*no ip address
*no ip route-cache
*no atm ilmi-keepalive
*pvc 0/35
* encapsulation aal5mux ppp dialer
* dialer pool-member 1
*!
*dsl equipment-type CPE
*dsl operating-mode GSHDSL symmetric annex B
*dsl linerate AUTO
!
interface Dialer1
*ip unnumbered Ethernet0
*encapsulation ppp
*dialer pool 1
*dialer-group 1
no cdp enable
*ppp authentication pap callin
*ppp pap sent-username password 7 xxxxxxxxxxxxxx
!
ip classless ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server
!
access-list 23 remark ACL voor VTY toegang access-list 23 permit 10.0.0.0
0.255.255.255 access-list 23 permit 213.144.0.0 0.0.255.255 dialer-list 1
protocol ip permit
no cdp run
!
line con 0
*password 7 0215105A19110E335F
*login
*stopbits 1
line vty 0 4
*access-class 23 in
*password 7 00170707164C0A141C
*login
*transport input telnet
!
scheduler max-task-time 5000
end


PIX:

: Saved
:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxxxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxxxxxx encrypted
hostname pixfirewall
domain-name contactdata.nl
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
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list inside_outbound_nat0_acl permit ip 192.168.18.0 255.255.255.0 192.16
8.19.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip 192.168.18.0 255.255.255.0 192.16
8.1.0 255.255.255.240
access-list outside_cryptomap_20 permit ip 192.168.18.0 255.255.255.0 192.168.19
..0 255.255.255.0
access-list VPN-CONTACTDATA_splitTunnelAcl permit ip 192.168.18.0 255.255.255.0
any
access-list outside_cryptomap_dyn_20 permit ip any 192.168.1.0 255.255.255.240
access-list outside_access_in permit tcp 213.144.234.0 255.255.255.0 interface o
utside eq smtp
access-list outside_access_in permit tcp any interface outside eq https
access-list inside_access_in permit tcp host 192.168.18.10 any eq smtp
access-list inside_access_in deny tcp any any eq smtp
access-list inside_access_in permit ip any any
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 10.25.1.74 255.255.255.0
ip address inside 192.168.18.220 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPN_POOL 192.168.1.1-192.168.1.10
pdm location 10.25.0.0 255.255.255.0 outside
pdm location 192.168.19.0 255.255.255.0 outside
pdm location 192.168.18.10 255.255.255.255 inside
pdm location 213.144.235.0 255.255.255.192 outside
pdm location 213.144.234.0 255.255.255.0 outside
pdm location 66.77.144.0 255.255.254.0 outside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface smtp 192.168.18.10 smtp netmask 255.255.25
5.255 0 0
static (inside,outside) tcp interface https 192.168.18.10 https netmask 255.255.
255.255 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 10.25.1.73 1
timeout xlate 0:05: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 sip-disconnect 0:02:00 sip-invite 0:03: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 10.25.0.0 255.255.255.0 outside
http 10.25.1.0 255.255.255.0 outside
http 192.168.18.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
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto map outside_map 20 ipsec-isakmp
crypto map outside_map 20 match address outside_cryptomap_20
crypto map outside_map 20 set peer 10.25.1.61
crypto map outside_map 20 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
isakmp enable outside
isakmp key ******** address 10.25.1.61 netmask 255.255.255.255 no-xauth no-confi
g-mode
isakmp nat-traversal 20
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup VPN-CONTACTDATA address-pool VPN_POOL
vpngroup VPN-CONTACTDATA dns-server 192.168.18.10
vpngroup VPN-CONTACTDATA split-tunnel VPN-CONTACTDATA_splitTunnelAcl
vpngroup VPN-CONTACTDATA idle-time 1800
vpngroup VPN-CONTACTDATA password ********
telnet timeout 9
ssh 66.77.144.0 255.255.254.0 outside
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 9
console timeout 0
dhcpd address 192.168.18.221-192.168.18.252 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
terminal width 80
Cryptochecksum:7629b127e7570cd3973a4c5ad15c91c4
: end

In article <>,
damn <> wrote:
>My customer contacted me, telling me that he couldn't reach his webserver
>anymore.

>I looked at the router for the first time, and couldn't find any (!) NAT
>or PAT related command.

>Still the clients were able to surf the net.

>Can anyone make any sence of this ?!? How is the NAT happening?

I'm not sure, but it looks to me as if it could be that your ISP
is (or was) doing the NAT. I don't know how common that is there;
it is not common here in Canada, but in the USA there are a couple
of big residential ISPs that use RFC1918 private addresses
internally and NAT at the edge of the network.

damn schrieb:

> Hi all,
>
> I got a basic Cisco knowledge but a good networking knowledge and I just
> ran into somehting I simply can't explain.
>
> My customer contacted me, telling me that he couldn't reach his webserver
> anymore.
>
> I figured that something was wrong with PAT to port 443.
>
> I looked at the router for the first time, and couldn't find any (!) NAT
> or PAT related command.
>
> Still the clients were able to surf the net. In between the router and the
> clients is also a PIX that does a VPN to another office, so I figured that
> the NAT was happening on that side, but now the customer tells me that
> they are still able to surf when the VPN is down !!!
>
> I attached the config of the Cisco and the PIX located at the first site.
>
> Can anyone make any sence of this ?!? How is the NAT happening?
>
Well, I`m no expert, but these lines:
....
# global (outside) 1 interface
# nat (inside) 0 access-list inside_outbound_nat0_acl
# nat (inside) 1 0.0.0.0 0.0.0.0 0 0
....
do exactly that - at least the nat part.

this line should do the port-translation for https:
# static (inside,outside) tcp interface https 192.168.18.10 https
netmask 255.255. 255.255 0 0

Has perhaps the ip of the webserver changed ?


.... ACL voor VTY toegang access-list 23 permit 10.0.0.0 -> for
walking on toes ???

>
> thx a mille!
>
> B.
>

hope it helps,
Dirk

agreed, but that's on the PIX, which is behind the router that's
connected to the internet. So how are the packets going out with the
correct source address then?



On Mon, 13 Mar 2006 14:18:09 -0800, Dirk Westfal wrote:

>
> damn schrieb:
>
>> Hi all,
>>
>> I got a basic Cisco knowledge but a good networking knowledge and I just
>> ran into somehting I simply can't explain.
>>
>> My customer contacted me, telling me that he couldn't reach his webserver
>> anymore.
>>
>> I figured that something was wrong with PAT to port 443.
>>
>> I looked at the router for the first time, and couldn't find any (!) NAT
>> or PAT related command.
>>
>> Still the clients were able to surf the net. In between the router and the
>> clients is also a PIX that does a VPN to another office, so I figured that
>> the NAT was happening on that side, but now the customer tells me that
>> they are still able to surf when the VPN is down !!!
>>
>> I attached the config of the Cisco and the PIX located at the first site.
>>
>> Can anyone make any sence of this ?!? How is the NAT happening?
>>
> Well, I`m no expert, but these lines:
> ...
> # global (outside) 1 interface
> # nat (inside) 0 access-list inside_outbound_nat0_acl
> # nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> ...
> do exactly that - at least the nat part.
>
> this line should do the port-translation for https:
> # static (inside,outside) tcp interface https 192.168.18.10 https
> netmask 255.255. 255.255 0 0
>
> Has perhaps the ip of the webserver changed ?
>
>
> ... ACL voor VTY toegang access-list 23 permit 10.0.0.0 -> for
> walking on toes ???
>
>>
>> thx a mille!
>>
>> B.
>>
>
> hope it helps,
> Dirk

"Dirk Westfal" <> wrote in message
news: oups.com...
>
> damn schrieb:
>
>> Hi all,
>>
>> I got a basic Cisco knowledge but a good networking knowledge and I just
>> ran into somehting I simply can't explain.
>>
>> My customer contacted me, telling me that he couldn't reach his webserver
>> anymore.
>>
>> I figured that something was wrong with PAT to port 443.
>>
>> I looked at the router for the first time, and couldn't find any (!) NAT
>> or PAT related command.
>>
>> Still the clients were able to surf the net. In between the router and
>> the
>> clients is also a PIX that does a VPN to another office, so I figured
>> that
>> the NAT was happening on that side, but now the customer tells me that
>> they are still able to surf when the VPN is down !!!
>>
>> I attached the config of the Cisco and the PIX located at the first site.
>>
>> Can anyone make any sence of this ?!? How is the NAT happening?
>>
> Well, I`m no expert, but these lines:
> ...
> # global (outside) 1 interface
> # nat (inside) 0 access-list inside_outbound_nat0_acl
> # nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> ...
> do exactly that - at least the nat part.
>
> this line should do the port-translation for https:
> # static (inside,outside) tcp interface https 192.168.18.10 https
> netmask 255.255. 255.255 0 0
>
> Has perhaps the ip of the webserver changed ?
>
>
> ... ACL voor VTY toegang access-list 23 permit 10.0.0.0 -> for
> walking on toes ???
>
>>
>> thx a mille!
>>
>> B.
>>
>
> hope it helps,
> Dirk
>

You're right but the outside interface address is a private one
ip address outside 10.25.1.74 255.255.255.0

So the PIX allows the Nating from the inside to the dmz zone between the
PIX and the router.
But nothing in the router indicates that this address is then NATed by a
public one .

If the clients are able to surf the net, it would suggest that the traffic
is NATed at a higher level.
But without seeing the ISP configuration we cannot know where it happens,
and if it's a one-way PAT
or a full static translation of the PIX outside address.

I would suggest to register with dyndns to see what public IP you get
.. It may just have changed recently.
http://www.dyndns.com/services/dns/dyndns/

On Mon, 13 Mar 2006 23:10:22 +0000, mcaissie wrote:

> You're right but the outside interface address is a private one
> ip address outside 10.25.1.74 255.255.255.0
>
> So the PIX allows the Nating from the inside to the dmz zone between the
> PIX and the router.
> But nothing in the router indicates that this address is then NATed by a
> public one .
>
> If the clients are able to surf the net, it would suggest that the traffic
> is NATed at a higher level.
> But without seeing the ISP configuration we cannot know where it happens,
> and if it's a one-way PAT
> or a full static translation of the PIX outside address.
>
> I would suggest to register with dyndns to see what public IP you get
> . It may just have changed recently.
> http://www.dyndns.com/services/dns/dyndns/


Hi MCaissie!

Thx for your replay!
I figured that the public IP-address would be set when the ppp-dialer
interface is created. I already thought of doing a ping to a host with a
sniffer, to get the public IP-address determined. But that wouldn't fix
the PAT issue.
Perhaps it is indeed a good thing to contact the ISP, but I never heard of
ISP's taking care of PAT-business, sounds horribly administratively heavy
to me :-s


thx again!

B.