Quote:
So.. is my webserver accessible today?

Quote:

Quote:
So.. is my webserver accessible today?

Non-authoritative answer:
Name: rtr.ca
Address: 207.236.110.166

Quote:
How about now: what does this do:

http://rtr.ca/ <-- probably is fine

Quote:

and what does this do:

http://64.26.128.89/ <--- probably not fine, but does it timeout, or give an error back instead?

thanks

Quote:

Access Denied
You don't have permission to access the requested object. It is either read-protected or not readable by the server.

Quote:
How about now: what does this do:

http://rtr.ca/ <-- probably is fine

and what does this do:

http://64.26.128.89/ <--- probably not fine, but does it timeout, or give an error back instead?

thanks

# host rtr.ca 206.13.31.12
Using domain server:
Name: 206.13.31.12
Address: 206.13.31.12#53
Aliases:

rtr.ca has address 64.26.128.89

# host rtr.ca 206.13.28.12
Using domain server:
Name: 206.13.28.12
Address: 206.13.28.12#53
Aliases:

rtr.ca has address 64.26.128.89

# host rtr.ca 4.2.2.1
Using domain server:
Name: 4.2.2.1
Address: 4.2.2.1#53
Aliases:

rtr.ca has address 64.26.128.89

# host rtr.ca 216.231.41.2
Using domain server:
Name: 216.231.41.2
Address: 216.231.41.2#53
Aliases:

rtr.ca has address 64.26.128.89

# host rtr.ca 64.81.79.2
Using domain server:
Name: 64.81.79.2
Address: 64.81.79.2#53
Aliases:

rtr.ca has address 207.236.110.166

Quote:
I get access denied when I visit rtr.ca. My nameserver is pointing to 207.236.110.166.

[zippy:/] ip route

64.26.128.1      dev ppp0  scope link  src 64.26.128.89

207.236.110.0/24 dev eth0  scope link  src 207.236.110.166

10.0.0.0/8       dev eth1  scope link  src 10.0.0.2

default

        nexthop via 207.236.110.1  dev eth0 weight 1

        nexthop via 64.26.128.1    dev ppp0 weight 1

Quote:
Okay, one more time: DNS is updated now, and my site *should* be responding to pings to both addresses: 207.236.110.166 (old), and 64.26.128.89 (new).

[nathan@heorot nathan]$ dig rtr.ca

; <<>> DiG 9.2.1 <<>> rtr.ca
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28501
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;rtr.ca.                                IN      A

;; ANSWER SECTION:
rtr.ca.                 23604   IN      A       207.236.110.166

;; AUTHORITY SECTION:
rtr.ca.                 23604   IN      NS      ns2.granitecanyon.com.
rtr.ca.                 23604   IN      NS      ns1.rtr.ca.
rtr.ca.                 23604   IN      NS      ns1.granitecanyon.com.

;; ADDITIONAL SECTION:
ns1.granitecanyon.com.  153208  IN      A       205.166.226.38
ns2.granitecanyon.com.  153208  IN      A       69.67.108.10

;; Query time: 27 msec
;; SERVER: 192.168.168.2#53(192.168.168.2)
;; WHEN: Tue Nov  8 15:00:37 2005
;; MSG SIZE  rcvd: 143

[nathan@heorot nathan]$

Quote:
So, to be clear, you're trying to use your internal machines to connect to an external IP address that's actually a NATted address for an internal machine, right?

Quote:
To be honest, you're not providing quite enough information. The important thing here is whether the external IP addresses are doing incoming NAT for a web server that exists on the private network or if the web server is actually on the machine that has those external IP addresses.

Quote:
Huh? You see the packets enter the machine that's intended to receive the packets, but no one answers them? That's not a routing problem. If the packet reaches the machine that it's destined for, routing is done.

Quote:

It all works today, after a mere good night's sleep, with no changes made.

Quote:
That would be the Routing Fairy at work. You did leave a cross-over cable under your pillow as payment didn't you ?

Yes, of course! One of my super special cross-over cables, too!

Quote:
Cool. Does it work now?

Quote:

Maybe it will cure itself overnight again.. ?

iptables -A OUTPUT -t mangle -s $EXT_IP1 -d $LAN_SUBNET -j ROUTE --oif $LAN_NIC
iptables -A OUTPUT -t mangle -s $EXT_IP2 -d $LAN_SUBNET -j ROUTE --oif $LAN_NIC

Quote:
The reason you can't do that, as I've said many times, is that it's the firewall (or probably, more precisely, the NATting) that's causing the problem, not the routing. If you didn't have the firewall/NAT in place, it would all work fine as you configured it. Since it's the firewall/NAT that's causing the problem, you have to fix the firewall/NAT to fix the problem.

# Enable(1) IP spoofing filters

for nic in /proc/sys/net/ipv4/conf/* ; do

        echo 0 > $nic/accept_source_route       # disabled source routed packets

        echo 1 > $nic/rp_filter                 # prevent IP spoofing

done

echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter           # The DSL nic *must* allow spoofing

echo 0 >/proc/sys/net/ipv4/conf/${DSL_NIC}/rp_filter    # The DSL nic *must* allow spoofing

Quote:

In fact, you shouldn't have to do that source-based routing except for that your ISPs (or theirs) have intentionally broken open routing by denying packets whose source addresses aren't in their whitelist.