Take 2: Advanced routing: multiple FIREWALLED IPs

[Guest]

Archived from groups: comp.security.firewalls,comp.os.linux.networking,comp.os.linux.setup (More info?)

Ok, I thought I had this licked but I guess I was wrong. I now have a
totally strange situation where I can hit both external interfaces, but I
cannot do this from the one of the connected networks.

Here is the setup:

: My Network Router World
: 192.168.1.0/24 --- eth1 192.168.1.254
: eth0 216.108.119.176 --- net1
: eth2 192.168.0.254
: |
: +--- router ------------- net2
: 192.168.0.1 64.247.149.169

In this setup it seems that replies go out the same interface that they
came in from (good) and I can hit the webserver running on the router
(good) but not from the 64.247.149.0/24 network (bad).

In addition I get the following really strange results:

# ping 64.247.149.x

works fine but

# traceroute 64.247.149.65
traceroute to 64.247.149.65 (64.247.149.65), 30 hops max, 38 byte packets
1 192.168.0.254 (192.168.0.254) 2995.688 ms !H 2997.474 ms !H 2999.958 ms !H

and any connection to the 64.247.149.0/24 netwrok fails, as do incoming
connections from that network. Examining the output of tcpdump as best as
I can it appears that connections to and from the 64.247.149.0/24 network
generate arp requests for the given address which, of course, fail, but
requests coming in VIA that network do not generate the same arp requests.

Any help would be much appreciated!

Rudolf

To preclude questions, here some relevant information:

# cat /etc/network/interfaces
# The loopback interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 216.108.119.176
netmask 255.255.255.224
network 216.108.119.160
broadcast 216.108.119.223
gateway 216.108.119.161
up /bin/echo eth0 base >/tmp/log
#
# This is the GWNT interface
#
up ip route add 216.108.119.160/27 dev eth0 \
src 216.108.119.176 table tgnwt || true
up ip route add default via 216.108.119.161 \
table tgnwt || true
up ip route add 216.108.119.160/27 dev eth0 \
src 216.108.119.176 || true
up ip rule add from 216.108.119.176 \
table tgnwt || true

auto eth1
iface eth1 inet static
address 192.168.1.254
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

auto eth2
iface eth2 inet static
address 192.168.0.254
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255

up ip route add 192.168.0.0/24 dev eth2 src 192.168.0.254 \
table tnn || true
up ip route add 192.168.0.0/24 dev eth2 src 192.168.0.254 \
|| true
up ip route add default via 192.168.0.1 table tnn || true

up ip route add 64.247.149.0/24 via 192.168.0.1 \
dev eth2 || true
up ip route add 64.247.149.0/24 dev eth2 src 192.168.0.254 \
table tnn || true
up ip route add 64.247.149.0/24 dev eth2 src 192.168.0.254 \
|| true
up ip rule add from 192.168.0.254 table tnn || true


This is what ends up being in the tables as a result of that :

# ip rule show
0: from all lookup local
32764: from 192.168.0.254 lookup tnn
32765: from 216.108.119.176 lookup tgnwt
32766: from all lookup main
32767: from all lookup default

# ip route show
216.108.119.160/27 dev eth0 proto kernel scope link src
216.108.119.176
64.247.149.0/24 via 192.168.0.1 dev eth2
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.254
default via 216.108.119.161 dev eth0

# ip route show table tnn
64.247.149.0/24 dev eth2 scope link src 192.168.0.254
192.168.0.0/24 dev eth2 scope link src 192.168.0.254
default via 192.168.0.1 dev eth2

# ip route show table tgnwt
216.108.119.160/27 dev eth0 scope link src 216.108.119.176
default via 216.108.119.161 dev eth0

 

[Guest]

Archived from groups: comp.security.firewalls,comp.os.linux.networking,comp.os.linux.setup (More info?)

In comp.os.linux.setup Rudolf Potucek <potucek@acs1.acs.ucalgary.ca> wrote:
> : 192.168.1.0/24 --- eth1 192.168.1.254

Isn't x.x.x.254 usually reserved for broadcast?

> In addition I get the following really strange results:
> # ping 64.247.149.x
> works fine but
> # traceroute 64.247.149.65

Well, maybe your router doesn't route the traceroute ICMP packets.
Maybe you should check that.

> Any help would be much appreciated!

I'd start checking the router, since it looks that the problem is
located there.

Davide

--
| Is your job running? You'd better go catch it!
|
|
|

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Davide Bianchi wrote:

(snipped)

> Rudolf Potucek wrote:

> > : 192.168.1.0/24 --- eth1 192.168.1.254

> Isn't x.x.x.254 usually reserved for broadcast?


Both .0 and .255 are reserved. Broadcast is .255

192.168.1.0/24

This generates 254 host usable addresses:

192.168.1.1 through 192.168.1.254 inclusively.

Broadcast is 192.168.1.255


Purl Gurl
--

Cross posting removed to prevent newsgroup spamming.

 

[Guest]

Archived from groups: comp.security.firewalls,comp.os.linux.networking,comp.os.linux.setup (More info?)

In comp.os.linux.networking Davide Bianchi <davideyeahsure@onlyforfun.net> wrote:
: In comp.os.linux.setup Rudolf Potucek <potucek@acs1.acs.ucalgary.ca> wrote:
:> : 192.168.1.0/24 --- eth1 192.168.1.254

: Isn't x.x.x.254 usually reserved for broadcast?

Nope, that's 255

: Well, maybe your router doesn't route the traceroute ICMP packets.
: Maybe you should check that.


Be that as it may ... the point is that webtraffic also doesn't work ...

Rudolf

--
Ziller: And what did you feel [about killing 3492 people]?
Hub: Appalled. Compassion. Despair. Detached. Elated. God-like. Guilty.
Horrified. Miserable. Pleased. Powerful. Responsible. Soiled. Sorrowful.
Ziller: Elated? Pleased?
Hub: Those are the closest words. There is and undeniable elation in
causing mayhem, in bringing about such massive destruction. As for
feeling pleased, I felt pleasure that some of those who died did so
because they were stupid enough to believe in gods or afterlives that do
not exist, even though I felt a terrible sorrow for them as they died in
their ignorance and thanks to their folly. Ifelt pleasure that my weapon
and sensory systems were workinng as they were supposed to. I felt
pleasure that despite my midgiings I was able to do my duty and act as
I had determined a fully morrally responsible agent ought to, in the
circumstances.

-- Iain Banks, Look to Windward

 

[Guest]

Archived from groups: comp.security.firewalls,comp.os.linux.networking,comp.os.linux.setup (More info?)

DUH ... the problem is with the 64.x.x.x rule in table tnn ... for some
reason I don not entirely understand that rule seems to imply to the
kernel that the 64.x.x.x network should be a LOCAL network directly
connected to the interface. Removing that entry leads to all non-local
traffic going to the default gateway for that interface as intended.

Sorry for the static

Rudolf

--
The 3 'R's of Microsoft - Retry, Reboot, Reinstall...