Logix - our ISP / Internet Provider has made changes to the router that now prevents us from accessing our internal web site.
Basically, we have an IIS server that is available externally and internally - the external people (outside of our subnets) can access the web site, but people internally can NOT.
What causes this or what caused this?
Thanks.
In article , JJ wrote: :Logix - our ISP / Internet Provider has made changes to the router that now :prevents us from accessing our internal web site.
:Basically, we have an IIS server that is available externally and :internally - the external people (outside of our subnets) can access the web :site, but people internally can NOT.
:What causes this or what caused this?
There are several possibilities.
Are you using Network Address Translation? That is, is the "real" (internal) IP of the server different than what the public knows it as? And if so, then are you unable to get through to it through the public IP but -are- able to get through using the internal IP? If this is the case then the ISP has configured the router not to allow "looping back" through the same interface. [Not allowing this kind of loopback is normal for a Cisco PIX firewall, by the way.]
I believe that is the case (not sure on terminologies). Basically, we have a public DNS tha when it hits our ROUTER get translated (NATted) to a private IP (our IIS) address.
I am not sure about PIX (we only have the Cisco 1750) - small router that sits between Internet and Internal network.
Now the question is...is there a security risk by allowing loopback for that particular public DNS address and the internal server (NATted machine/IP)?
Thanks for the initial clarification.
Irregardless of security issues think of what you're proposing. A packet would enter the PIX on the Internal network interface just to turn around and exit again.
Setup split DNS so that external requesters will be given the external public IP address and internal requesters will get the internal private ID address.
In article , Rod Dorman wrote: :In article , :JJ wrote: :>I believe that is the case (not sure on terminologies). Basically, we have :>a public DNS tha when it hits our ROUTER get translated (NATted) to a :>private IP (our IIS) address.
:>I am not sure about PIX (we only have the Cisco 1750)
:Irregardless of security issues think of what you're proposing. A :packet would enter the PIX on the Internal network interface just to :turn around and exit again.
To clear up a bit of confusion: I'm the one who introduced the reference to the PIX; the OP does not have a PIX in the config.
My point in mentioning the PIX was to indicate that configuring so as to not allow turn-around packets is not a weird "Why did they *do* that?!" sort of configuration: it is a common configuration in some situations.
As to what actually happened: my suspicion is that they may have turned on "reverse path verification". The interface would then see the packets with your internal IP range as "going the wrong way" and so would block them.
NOTE: IP and names have been changed for security.
Well now, the ISP can not get the darn thing to work with our web site...they said they have to replaced the Cisco 1610 or 01 with an ADtran that does what we want (1 to 1 map of ext to int IP and have port filtering for each one).
interface Ethernet0 description private addresses for ethernet LAN ip address 216.201.100.17 255.255.255.248 secondary ip address 192.168.242.1 255.255.255.0 no ip directed-broadcast ip nat inside no ip route-cache ! interface Serial0 bandwidth 832 ip address 10.30.132.130 255.255.255.252 no ip directed-broadcast ip nat outside no fair-queue ! ip nat pool natpool 216.201.100.17 216.201.100.17 netmask 255.255.255.248 ip nat inside source list 2 pool natpool overload ip nat inside source static 192.168.242.5 100.100.100.101 ip nat inside source static 192.168.242.6 100.100.100.102 ip nat inside source static 192.168.242.19 100.100.100.100 ip classless ip route 0.0.0.0 0.0.0.0 Serial0 no ip http server ! access-list 2 permit 192.168.242.0 0.0.0.255 access-list 5 permit 209.49.5.13 access-list 5 permit 209.49.5.15 access-list 101 deny ip 216.201.134.56 0.0.0.7 any access-list 101 permit ip any 216.201.134.56 0.0.0.7 access-list 101 permit ip any 10.30.4.48 0.0.0.3 access-list 102 permit ip 10.30.4.48 0.0.0.3 any access-list 102 deny ip any 216.201.134.56 0.0.0.7 access-list 102 deny ip any 10.0.0.0 0.255.255.255 access-list 102 deny ip any 192.168.0.0 0.0.255.255 access-list 102 deny ip any 172.16.0.0 0.15.255.255 access-list 102 permit ip 216.201.134.56 0.0.0.7 any access-list 103 permit udp host 216.201.128.10 any gt 1023 access-list 103 permit udp host 66.196.216.10 any gt 1023 access-list 103 permit icmp any any access-list 103 permit tcp any any established access-list 2500 deny tcp any any eq 51233 access-list 2500 permit ip any any access-list 2520 deny tcp host 192.168.242.5 any eq smtp access-list 2520 permit ip any any snmp-server engineID local 0000000902000002FD6559FE snmp-server community cl1entm0n RO 5 snmp-server community cl1entmrite RW 5 banner motd ^CC
===============================
Support,
Please close all incoming ports to mypubdns.COM for the following IP Address / DNS:
MAIL.mypubdns.COM / USBI2004.mypubdns.COM
100.100.100.100Close all port incoming EXCEPT 25, 80, 443, 3389
VPN.mypubdns.COM
100.100.100.101Close all ports incoming EXCEPT 21, 80, 443, 1723, 4931, 1701, 3389
PORTAL.mypubdns.COM
100.100.100.102Cllose all ports incoming EXCEPT 80, 443, 3389
Our goal is to NOT allow any or all incoming ports to be open or scanned from the outside, and have only the above available.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.