Re: Accessing my Webserver from the outside - Pix 515E

PE-PatInBC · ‎03-18-2005

Previously posted in the wrong forum.

I can reach my webserver from any client through the inside interface but not from the outside. Please review my config. I have an outside interface of xxx.yyy.17.145 and I have setup this server to be accessed at xxx.yyy.17.146 which is one of the block of available IP addresses given to me by my ISP.

What logging might help me with this ? PDM Logging ?

Please let me know what I am doing wrong.

---------------------------------------------

PIX Version 6.3(4)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security4

enable password xxxxxxxx616Q encrypted

passwd xxxr616Q encrypted

hostname xxxxll1

domain-name xxxxxxxxxxxx

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

name xxx.yyy.90.0 MailNetwork

access-list outside_access_in remark

access-list outside_access_in permit tcp any host xxx.yyy.17.146 eq www

pager lines 24

logging on

logging timestamp

logging host inside 192.168.10.5

icmp permit any inside

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

ip address outside xxx.yyy.17.145 255.255.255.240

ip address inside 192.168.10.100 255.255.255.0

ip address DMZ 192.168.20.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm location 0.0.0.0 255.255.255.0 outside

pdm location 192.168.10.35 255.255.255.255 inside

pdm location 192.168.10.178 255.255.255.255 inside

pdm location 192.168.10.5 255.255.255.255 inside

pdm location MailNetwork 255.255.255.255 outside

pdm location 192.168.10.0 255.255.255.255 inside

pdm location 192.168.20.101 255.255.255.255 DMZ

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 200 interface

global (DMZ) 200 192.168.20.50-192.168.20.100

nat (inside) 200 192.168.10.0 255.255.255.0 0 0

static (DMZ,outside) xxx.yyy.17.146 192.168.20.101 netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

route outside 0.0.0.0 255.255.255.0 xxx.yyy.17.158 1

route outside 0.0.0.0 0.0.0.0 xxx.yyy.17.158 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.10.0 255.255.255.0 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

tftp-server inside 192.168.10.178 c:\tftp-root

floodguard enable

telnet 192.168.10.35 255.255.255.255 inside

telnet 192.168.10.178 255.255.255.255 inside

telnet 192.168.10.5 255.255.255.255 inside

telnet timeout 5

ssh timeout 5

console timeout 0

dhcpd lease 3600

dhcpd ping_timeout 750

dhcpd auto_config outside

terminal width 80

Cryptochecksum:xxxx

: end

[OK]

Patrick Iseli · ‎03-18-2005

Everything looks good have you reset the translation table after you changed the NAT configuration ?

Note: This will reset all connections, be carefully in business hours with that !!!

conf t

clear xlate

sincerely

Patrick

PE-PatInBC · ‎03-19-2005

Thank you Patrick,

Still no go. I am able to access the webserver from the private clients through the inside interface to the DMZ but nothing from the outside interface to the DMZ.

As I understand this, the first thing I need to do is make sure that all of the routing between the different interfaces is in place. Once that is good, I apply access lists for providing access to required services. How could I test the NAT from the outside to the DMZ ? What logging might help and what should I be looking for ?

Any other suggestions ?

PE-PatInBC · ‎03-21-2005

Quick question

1) Should I be able to ping the xxx.yyy.17.246 address that I have assigned for the webserver ? The route has been created as Patrick mentioned. I think I'm missing something fundamental here.

2) Should I be using my outside interface address instead for the route ? xxx.yyy.17.145 instead of xxx.yyy.17.146 ?

3) What logs would provide the best information ? Syslogs, PDM Logging ? ?????

I am knew enough to this that I haven't used the logging before. Any assistance would be greatly appreciated.

Pat

Patrick Iseli · ‎03-21-2005

A1: NO you will not be able to ping. Ping is not stateful you will need to open the ping on the outside interface.

Handling ICMP Pings with the PIX Firewall

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

The PIX and the traceroute Command

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00800e9312.shtml

A2: It does not really matter if you use xxx.yyy.17.145 or xxx.yyy.17.146. But the config will change.

Option xxx.yyy.17.145 mean that you need to configure port redirection instaed of NAT.

Option xxx.yyy.17.146 as used right now will be used in conjunction with NAT. Allows you to open all ports as necessary without limitation.

A3: Syslog and PDM and "show logg" on the console will basicly provide the same information if the logging level is the same. Normaly "logging buffer warning" gives enough information to analyze troubles. You can also send them to a syslog server wich allows easyer troubleshooting in a text file with the FIND function of your prefered text file editor.

logg on

logg buff warn

sincerely

Patrick

PE-PatInBC · ‎03-23-2005

I have now got logging working to a syslog server and am getting the following error:

---------------------------------------------------

Mar 23 2005 09:31:04: %PIX-3-305005: No translation group found for udp src inside:192.168.20.101/2981 dst outside:192.168.0.20/53

and the following warning:

----------------------------------------------------

Mar 23 2005 09:32:06: %PIX-4-405001: Received ARP request collision from 192.168.10.100/000f.1f6e.7878 on interface inside

I found the following explaination for the error but it looks like everything is in place. I'm not sure why I'm getting the error 192.168.0.20 address as I don't have anything on that subnet internally.

Can I confirm the NAT on my OUTSIDE interface to my DMZ webserver ? Any other thoughts ?

Patrick Iseli · ‎03-23-2005

Thats absolutly right !

You have setup:

global (DMZ) 200 192.168.20.50-192.168.20.100

And 192.168.20.101 is not part of the allowed PAT (NAT) range 192.168.20.50-192.168.20.100 so this host cannot connect outside.

Where, which interface, is this DNS host 192.168.0.20.

I cannot see it in the interface and you do not have a route or NAT.

Add another range to it !

example:

global (DMZ) 200 192.168.20.101-192.168.20.150

sincerely

Patrick

mhussein · ‎03-23-2005

Hi,

Just 2 quick observations here:

1.

The DMZ interface ip address is configured:

ip address DMZ 192.168.20.1 255.255.255.0

and the error message:

%PIX-3-305005: No translation group found for udp src inside:192.168.20.101/2981 dst outside:192.168.0.20/53

shows that host 192.168.20.101 shouldn't be connected to the inside, it should be on the dmz (inside is 192.168.10.0/24 and dmz is 192.168.20.0/24). May be you need to check the PIX cabling, the inside and outside interfaces are on the chassis while the dmz interface (ethernet2) is on the pci slot. There shouldn't be a switch interconnecting the pix interfaces.

2.

The inside interface is configured:

ip address inside 192.168.10.100 255.255.255.0

and the error message:

%PIX-4-405001: Received ARP request collision from 192.168.10.100/000f.1f6e.7878 on interface inside

Is it possible that the machine with MAC-OUI 000f.1f6e.7878 (possibly a Dell system) is conflicting with the pix's inside ip address?

Could you post the arp caches content (show arp inside, show arp dmz)?

Regards,

Mustafa

PE-PatInBC · ‎03-23-2005

Thanks to both of you.

Mustafa, I'm guilty and you were correct. I didn't have the DMZ on a dedicated physical network. I just moved it to one and now the log says

Mar 23 2005 14:50:55: %PIX-4-106100: access-list outside_access_in permitted tcp outside/209.53.227.66(3416) -> DMZ/xxx.xxx.17.146(80) hit-cnt 1 (first hit)

That looks alot better but I still can't get the webpage to come up. I am looking at the webserver now to see if I'm missing something but if I type

http://192.168.20.101

or

http://192.168.20.101/index.htm

from clients accessing the inside interface as their gateway, I get a webpage. Any thoughts ?

PE-PatInBC · ‎03-23-2005

ARP cache as requested.

Pix# show arp

inside 192.168.10.5 0050.bad3.1cd6

inside 192.168.10.178 0007.e90b.b642

inside 192.168.10.38 0007.e90b.b07a

inside 192.168.10.25 000f.1f6e.7877

inside 192.168.20.101 0002.b3ab.66dd

DMZ 192.168.20.101 0002.b3ab.66dd

I removed the outside interface but if you need it too let me know.

mhussein · ‎03-23-2005

Host 192.168.20.101 still appears on 2 sides of the firewall:

inside 192.168.20.101 0002.b3ab.66dd

DMZ 192.168.20.101 0002.b3ab.66dd

Try clearing the arp-cache and the translations again:

clear arp

clear xlate

And check that host 192.168.20.101 is on dmz:

show arp

show xlat

sho local-host 192.168.20.101

Regards,

Mustafa

PE-PatInBC · ‎03-23-2005

Done as requested. Here is the results:

------------------------------------------

PE-Wall1# sh arp

inside 192.168.10.5 0050.bad3.1cd6

DMZ 192.168.20.101 0002.b3ab.66dd

PE-Wall1# sh xlate

1 in use, 45 most used

Global xxx.xxx.17.146 Local 192.168.20.101

PE-Wall1# sh local-host 192.168.20.101

Interface DMZ: 1 active, 1 maximum active, 0 denied

local host: <192.168.20.101>,

TCP connection count/limit = 0/unlimited

TCP embryonic count = 0

TCP intercept watermark = unlimited

UDP connection count/limit = 0/unlimited

AAA:

Xlate(s):

Global xxx.xxx.17.146 Local 192.168.20.101

Conn(s):

Interface inside: 0 active, 2 maximum active, 0 denied

----------------------------------------------

Still no access to a webpage through the outside interface translation. Nothing that I can see in the logs that says that there is any problem but it just won't show the page.

mhussein · ‎03-23-2005

Last thing I can think of is the default gateway on host 192.168.20.101 should be set to 192.168.20.1 (pix dmz interface).

From 192.168.20.101 try to browse to http://www2.cotse.com/cgi-bin/test.cgi or use proxy test http://www.all-nettools.com/toolbox to see what ip address is being used.

On the log, look for "translation/connection built/tear down" etc..., and check the access-list hit count.

PE-PatInBC · ‎03-24-2005

Yes the DMZ is a completely separate network and it needs to know where to go when it can't find something on it's own network, so having the correct gateway address allows the request to be returned. I changed the gateway address on the web server and it works.

Patrick and Mustafa, you guys are amazing. Thank you for all of your assistance.

PE-PatInBC · ‎03-25-2005

%PIX-4-405001: Received ARP request collision from 192.168.10.100/000f.1f6e.7878 on interface inside

Mustafa,

You mentioned in your above commment above that my conflict might be with a Dell Server. Once again, right you are. the second address that is conflicting is 000f.1f6e.7877

Here is a SHOW ARP from my PIX

PE-Wall1# sh arp

outside xxx.xxx.17.158 0012.7f32.9ce1

inside 192.168.10.25 000f.1f6e.7877

inside 192.168.10.5 0050.bad3.1cd6

inside 192.168.10.178 0007.e90b.b642

inside 192.168.10.38 0007.e90b.b07a

inside 192.168.10.35 000f.1f23.184d

DMZ 192.168.20.101 0002.b3ab.66dd

DMZ 192.168.20.100 0007.e90b.b6b3

What can be done about this ? Is it conflicting with the inside interface on the PIX ?