firewall setup and routing

Hi all,

I have a RH9 box setup as my default gateway on our network. The box
has two NICs, one connected to the internet (via cable) and one to our
internal network. On the box, I am performing basic SNAT-ing and
DNAT-ing for the network using iptables. This works perfect.

-A PREROUTING -d EXTERNAL -i eth0 -p tcp -m tcp --dport 3389 -j DNAT
--to-destination 192.111.111.9
-A PREROUTING -d EXTERNAL -i eth0 -p tcp -m tcp --dport 6881 -j DNAT
--to-destination 192.111.111.9
-A PREROUTING -d EXTERNAL -i eth0 -p tcp -m tcp --dport 6882 -j DNAT
--to-destination 192.111.111.9
-A PREROUTING -d EXTERNAL -i eth0 -p tcp -m tcp --dport 6883 -j DNAT
--to-destination 192.111.111.9
-A PREROUTING -d EXTERNAL -i eth0 -p tcp -m tcp --dport 6884 -j DNAT
--to-destination 192.111.111.9
-A POSTROUTING -s 192.111.111.0/255.255.255.0 -o eth0 -j SNAT
--to-source EXTERNAL

Now,

We have a remote site that's on a different subnet and its connected
to our network VIA a VPN server (W2K server) on both sides.

Our internal ip address range (local network) is 192.111.111.x (dont
ask me why, ask the muppet who set up this network).
On the linux box I am adding a static route to destination 192.168.1.2
via 192.111.111.211 (which is our VPN server).

route add -net 192.168.1.0/24 gw 192.111.111.211

The route is accepted fine however, none of my machines are able to
connect to the remote network.

Am I doing anything wrong? Can anyone help?

Thanks in advance.

Roberto

Hi Roberto,

Ah, so you have a puzzle, too, eh? I think what I would do first is
run tcpdump on the internal LAN to see what kind of traffic is being
generated when a local user tries to connect to the remote VPN site.
That should provide some clues. You can then try to track things down
by running tcpdump on the internal and external interfaces of the VPN
server and/or the gateway machine until you find where the traffic is
being stopped. You might also want to turn on logging for dropped
packets on your gateway machine -- then you could see if Netfilter is
the culprit, and what to do about it. My personal bias is always to
suspect the Microsoft components, though ;-)

Tim

Hi Tim,

Thanks for your suggestions. I tryed almost all of it before I posted
but had no luck. Then I decided to reboot the linux box (firewall) and
was greeted by a pleasant surprise. The routing simply worked
strqaight away. I dont know how the reboot affected the setup but now
all routing and IPTABLES functions work fine.

I forgot to mention that I am also performing some bandwidth measuring
on the gateway machine with NTOP so I am suspecting that it could have
had some effect on the routing.

Either way, its all working now.

Thanks again for your suggestions.

Roberto



(E-Mail Removed) (TN) wrote in message news:<(E-Mail Removed) om>...
> Hi Roberto,
>
> Ah, so you have a puzzle, too, eh? I think what I would do first is
> run tcpdump on the internal LAN to see what kind of traffic is being
> generated when a local user tries to connect to the remote VPN site.
> That should provide some clues. You can then try to track things down
> by running tcpdump on the internal and external interfaces of the VPN
> server and/or the gateway machine until you find where the traffic is
> being stopped. You might also want to turn on logging for dropped
> packets on your gateway machine -- then you could see if Netfilter is
> the culprit, and what to do about it. My personal bias is always to
> suspect the Microsoft components, though ;-)
>
> Tim

(E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> Hi Tim,
>
> Thanks for your suggestions. I tryed almost all of it before I posted
> but had no luck. Then I decided to reboot the linux box (firewall) and
> was greeted by a pleasant surprise. The routing simply worked
> strqaight away. I dont know how the reboot affected the setup but now
> all routing and IPTABLES functions work fine.
>
> I forgot to mention that I am also performing some bandwidth measuring
> on the gateway machine with NTOP so I am suspecting that it could have
> had some effect on the routing.
>
> Either way, its all working now.
>
> Thanks again for your suggestions.
>
> Roberto
[snip]

Not clear what all you were changing _before_ rebooting, but my guess
is you failed to clear the arp/route caches (especially the route
cache) -- the caches are checked first and any routing there will
trigger the forwarding code _without_ reading the routing table(s)
regardless of any changes made to them ;-)

Lesson -- whenever you make changes to the routing tables, be sure to
flush the route cache.

prg
email above disabled

Well,

It seems that I celebrated too early. Routing works fine for about
15-20 minutes and then misteriously stops. If I restart the network
service routing starts to work again for the same amount of time and
then stops again...
Very misterious, at least to me.
Anyone kind enough to make a guess?

Thanks
Roberto


(E-Mail Removed) (P Gentry) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> > Hi Tim,
> >
> > Thanks for your suggestions. I tryed almost all of it before I posted
> > but had no luck. Then I decided to reboot the linux box (firewall) and
> > was greeted by a pleasant surprise. The routing simply worked
> > strqaight away. I dont know how the reboot affected the setup but now
> > all routing and IPTABLES functions work fine.
> >
> > I forgot to mention that I am also performing some bandwidth measuring
> > on the gateway machine with NTOP so I am suspecting that it could have
> > had some effect on the routing.
> >
> > Either way, its all working now.
> >
> > Thanks again for your suggestions.
> >
> > Roberto
> [snip]
>
> Not clear what all you were changing _before_ rebooting, but my guess
> is you failed to clear the arp/route caches (especially the route
> cache) -- the caches are checked first and any routing there will
> trigger the forwarding code _without_ reading the routing table(s)
> regardless of any changes made to them ;-)
>
> Lesson -- whenever you make changes to the routing tables, be sure to
> flush the route cache.
>
> prg
> email above disabled

Just a quick update everyone,

It was a faulty NIC... thats why it worked for the first 15 minutes
and then it stopped

Ta

(E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> Well,
>
> It seems that I celebrated too early. Routing works fine for about
> 15-20 minutes and then misteriously stops. If I restart the network
> service routing starts to work again for the same amount of time and
> then stops again...
> Very misterious, at least to me.
> Anyone kind enough to make a guess?
>
> Thanks
> Roberto
>
>
> (E-Mail Removed) (P Gentry) wrote in message news:<(E-Mail Removed). com>...
> > (E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> > > Hi Tim,
> > >
> > > Thanks for your suggestions. I tryed almost all of it before I posted
> > > but had no luck. Then I decided to reboot the linux box (firewall) and
> > > was greeted by a pleasant surprise. The routing simply worked
> > > strqaight away. I dont know how the reboot affected the setup but now
> > > all routing and IPTABLES functions work fine.
> > >
> > > I forgot to mention that I am also performing some bandwidth measuring
> > > on the gateway machine with NTOP so I am suspecting that it could have
> > > had some effect on the routing.
> > >
> > > Either way, its all working now.
> > >
> > > Thanks again for your suggestions.
> > >
> > > Roberto
> > [snip]
> >
> > Not clear what all you were changing _before_ rebooting, but my guess
> > is you failed to clear the arp/route caches (especially the route
> > cache) -- the caches are checked first and any routing there will
> > trigger the forwarding code _without_ reading the routing table(s)
> > regardless of any changes made to them ;-)
> >
> > Lesson -- whenever you make changes to the routing tables, be sure to
> > flush the route cache.
> >
> > prg
> > email above disabled

(E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> Just a quick update everyone,
>
> It was a faulty NIC... thats why it worked for the first 15 minutes
> and then it stopped
>
> Ta
[snip]

Glad you caught it ;-)

Hardware nic problems _are_ tricky to catch -- we always assume it's a
misconfiguration somewhere.

Keeps us honest ...

prg