Do I Have A Firewalled LAN Run By ISP In Between?

  1. I have a (wireless) router set up in "gateway mode." Hosts on the LAN are dynamically assigned 192.168.1.x addreses, and the router itself is
192.168.1.1 (note the subnet mask is 255.255.255.240, giving up to--- what?---16 hosts).

  1. When I interface with the router (via web interface) to check for its WAN IP assignment, I get to my astonishment the following:

IP Address: 10.202.46.2 Subnet Mask: 255.255.255.0 Default Gateway: 10.202.46.1 DNS 1: 10.202.46.1

Of course, I am astonished because 10.x.x.x. are also designated for private LAN and not Internet IP addresses, right?

  1. I have access to a host "on the Internet" (169.237.x.x) through a remote desktop connection (which can be made!) and so can follow all sorts of TCP activity (ftp, http) from that host while at host 192.168.1.3. This remote host is running FileZilla ftp server and I can monitor attempts to connect and IP addresses. When I attempt to use FireFTP (an "extension" creating an ftp client within the FireFox http client), the FileZilla server monitor on the remote host reports that my IP address is
64.30.y.y, and not 10.202.46.2, which is consistent with my understanding that 10.x.x.x addresses are private.

That means that the ISP must be "onion"ing its network: that is, providing service as a layer or shell of its own private network, and running a layer within a layer, with a complex network address translation system. Is that possible??

At any rate, I am not concerned about how they configure their networks. I am ONLY concerned that they are or might be firewalling inbound port 80 service, or for that matter, any service.

QUESTION: What is going on here? I have additional information below which may be helpful.

  1. When I attempt to connect to the FileZilla server on the remote host through the FireFTP client, I can login, but I cannot start a file transfer. I always get a
425 Can't get data connection

error.

  1. In attempting to monitor traffic through various hosts, I have been trying to enable logging or other kinds of monitors.

(a) the router has its own logging feature which I have enabled, but it only shows "outgoing" traffic to various unrecognizable IP addresses as destinations and all the hosts 192.168.x.x. on the LAN as sources and the ports are usually "www" (assuming port 80), "ftp" (assuming port 21) and strangely, port 500 (is this a known security exploit?)

(b) I am looking for monitoring software to use on the 192.168.1.3 host running IIS web server (on a Vista Premium windows environment), which I also want to use for ftp for large file transfers. I will probably install Wireshark, which is probably overkill for the monitoring I need.

QUESTION: are there other ways to monitor my attempts to request http service from the remote host...to see if it is getting to the target host, or at least to the router? How does one enable logging on IIS? It's not obvious, and I probably should be using Apache anyway.

Reply to
Patient Guy
Loading thread data ...

Yes. Your ISP appears to be using 10.* addresses for its own network. This is perfectly acceptable, provided they are hidden from the rest of the Internet. The potential downside is that you can't have inbound connectivity to your network.

University of California, Davis UCDAVIS2 (NET-169-237-0-0-1) 169.237.0.0 - 169.237.255.255

It's quite possible that your 64.30.* address is part of the public IP address range for UCD.

Clearly it's possible because it's happening. Your router is using NAT to hide your network behind a single IP address. Your ISP is doing exactly the same - hiding its network (and your single "public" IP address) behind one or more IP addresses.

Almost certainly yes.

I don't see that inbound connections to your network are relevant to this problem. I think you may be mixing things up a little. But, to resolve this error try switching your FTP client to "passive" mode.

Chris

Reply to
Chris Davies

Chris Davies wrote in comp.security.firewalls:

don't think so. This is what the FileZilla server on the UCD host is showing during attempts to make an FTP connection from the host with IP

10.202.46.2 above using the ftp client. That is,

router NAT ISP NAT 192.168.1.3 ---------> 10.202.46.2 ------> 64.30.y.y ---> Internet

Internet ---> host 169.237.x.x running FileZilla ftp server

Why would the ISP stop my ftp client on 192.168.1.3 making requests to the server fully outside of it at host 169.237.x.x? I figure if I can solve at least that problem, I might be able to solve the problem of providing http service on 192.168.1.3....possibly. Sort of the one problem solved leads possibly to another problem solved.

Oh, and that 425 error does happen in PASV mode.

Reply to
Patient Guy

Yup - see RFC1878 available through any search engine.

Sort of. See RFC1918, and read the rational for using those addresses, specifically section 2.

ARIN says that's UC Davis. Hope you have permission to be using it for non-school activities. Are you sure their firewall isn't blocking?

Well, you are posting from 64.30.107.165 which belongs to "SureWest Broadband" out of McClellan - they're a residential provider.

Web Results 1 - 10 of about 1,660,000 for Windows Connection Sharing. (0.19 seconds)

When microsoft invented the Internet, they eventually added an application called "Internet Connection Sharing". It's yet another idea they stole from the world and mis-implemented called "Network Address Translation", or NAT. For example,

1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT=22714 bytes) (Obsoleted by RFC3022) (Status: INFORMATIONAL)

That RFC documented a concept that had been developed before 1992. "Onion Routing" is a piece of techno-babble that describes how to use NAT to attempt to hide your IP address from the places you are surfing to.

Good, because all you can do is pay them for a commercial service rather than your residential service.

Let's look at the windoze "Internet Connection Sharing" concept. You may have ten or a hundred systems hiding behind a real (non-RFC3330) address like 64.30.107.165. Someone tries to connect to port 80 on

64.30.107.165 - which of the hidden systems should those packets be forwarded to? Now it's not impossible that they may be blocking access to servers run on a residential network, because they want you to pay for a commercial connection. You'd have to read the agreement you have with your provider, or at least ask them.

You need to understand more about how the Internet works.

0959 File Transfer Protocol. J. Postel, J. Reynolds. October 1985. (Format: TXT=147316 bytes) (Obsoletes RFC0765) (Updated by RFC2228, RFC2640, RFC2773, RFC3659) (Also STD0009) (Status: STANDARD) 1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: TXT=8806 bytes) (Status: INFORMATIONAL)

I don't bother using toy applications for network services, but see if your application knows about the 'Passive' mode. However, this problem is probably quite different from problems you may be having with trying to run a web _server_ from a NATed connection.

One of the services using port 500 is VPN Key Exchange.

Wireshark is a packet sniffer - probably useless if you don't know what those packets are for, or understand the protocols involved.

1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding, H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: INFORMATIONAL) 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes RFC2068) (Updated by RFC2817) (Status: DRAFT STANDARD)

The "commands" over the wire are ASCII text, and while not exactly simple English, are relatively easy to read.

A packet sniffer will tell a lot - but you've got to be able to understand what is in the packets, why it it there, and how the dozens of protocols that may be in those packets differ.

Old guy

Reply to
Moe Trin

Note also: How are you connecting to your ISP? Is it DSL? I also saw a double-nat situation with a DSL modem and a customer supplied router. As it turned out, the ISP wasn't doing nat and was giving a publically reachable IP(v4) address. What was happening was that the DSL modem also had nat built into it and it was enabled. That's when I first learned that some DSL modems, although they only have ONE user port, are also nat boxes. A "one port nat box" device doesn't make much sense, but they do exist. Therefore, what you could be seeing is a double nat due to your DSL modem - and your router is getting a DHCP address in 10/8 from your DSL modem.

192.168.1.0/24 (your net & router) === 10.0.0.0/8 (your DSL modem) === 64.30.0.0/16 (your ISP "Level 3 Comm.")

Therefore - be careful. Your ISP itself might not be natting. It might be your DSL modem.

The Westell 6000 and 6100 are examples of "one port natting DSL modems."

Reply to
D. Stussy

Patient Guy wrote: P> 1. I have a (wireless) router set up in "gateway mode." Hosts on the P> LAN are dynamically assigned 192.168.1.x addreses [...]

P> 2. When I interface with the router (via web interface) to check for P> its WAN IP assignment, I get to my astonishment the following: P> IP Address: 10.202.46.2

P> 4. I have access to a host "on the Internet" (169.237.x.x) [...]

Chris Davies wrote in C> It's quite possible that your 64.30.* address is part of the public IP C> address range for UCD.

P> don't think so. This is what the FileZilla server on the UCD host is P> showing during attempts to make an FTP connection from the host with IP P> 10.202.46.2 above using the ftp client. That is,

P> router NAT ISP NAT P> 192.168.1.3 ---------> 10.202.46.2 ------> 64.30.y.y ---> Internet P>

P> Internet ---> host 169.237.x.x running FileZilla ftp server

I think that's what I said. (Well, I know what I said; I'm trying to interpret your addresses.) It looks like 64.30.* is the public side of your ISP.

The "missing piece" is an assumption that UCD /is/ your ISP.

P> Why would the ISP stop my ftp client on 192.168.1.3 making requests to the P> server fully outside of it at host 169.237.x.x?

I don't think this is an intentional fault.

P> Oh, and that 425 error does happen in PASV mode.

Mmm, that really surprises me. What happens if you switch to active mode, then?

P> I might be able to solve the problem of providing P> http service on 192.168.1.3....possibly.

No chance. Serving HTTP requires inbound service, which you won't have through (two layers of) NAT. An FTP client is an outbound service, which should work through properly implemented NAT.

Finally, as a thought... do you really need to use FTP or can you use one of the secure protocols such as SFTP?

Chris

Reply to
Chris Davies

The original post (Message-ID: ) (207.115.x.x is the news server) had these two headers:

NNTP-Posting-Host: 64.30.107.165 X-Trace: newssvr14.news.prodigy.net 1204481029 ST000 64.30.107.165 (Sun, 02 Mar 2008 13:03:49 EST)

Yes

No.

[compton ~]$ bzgrep '|64.30.' IP.ADDR/stats/delegated-arin-20080215.bz2 arin|US|ipv4|64.30.0.0|16384|20000119|allocated arin|US|ipv4|64.30.64.0|8192|20040830|allocated arin|US|ipv4|64.30.96.0|8192|20010419|allocated arin|US|ipv4|64.30.128.0|4096|20071114|allocated arin|US|ipv4|64.30.160.0|8192|20010424|allocated arin|US|ipv4|64.30.192.0|8192|20000124|allocated arin|US|ipv4|64.30.224.0|4096|20010503|allocated arin|US|ipv4|64.30.240.0|4096|20040622|assigned [compton ~]$

OrgName: SureWest Broadband OrgID: SUREW Address: 5411 Luce Ave City: McClellan StateProv: CA PostalCode: 95652 Country: US

NetRange: 64.30.96.0 - 64.30.127.255 CIDR: 64.30.96.0/19 NetName: SUREWEST-64-30 NetHandle: NET-64-30-96-0-1

About 18 miles / 30 KM Northeast of UC Davis. Of the others, only

64.30.192.0/19 (a commercial provider) is in California (about 380 miles / 620 KM Southeast).

Old guy

Reply to
Moe Trin

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.