Re: Multi-ISP configuration problem

Brad Clarke
Sat, 12 Apr 2008 19:27:16 -0000

On Sat, Apr 12, 2008 at 9:56 AM, Tom Eastep <teastep@shorewall.net>
wrote:
>
>  That''s because 216.111.163.33 isn''t the IP address of
any of the firewall
> interfaces. The firewall''s eth1 interface has an address that is
close:

I knew I was doing something stupid but I thought it was in the
configuration not in my testing :) This part was already working as
expected.

> >
> >  I had VPN connections from an internal address (192.168.10.x) to
> >  either of the external addresses routing the connection back to the
> >  internal VPN server.
> >
>
>  Actually, you don''t. You have what appear to be these rules:
>
>  DNAT    $FW     loc:192.168.10.17 tcp   1723    - 207.111.163.33
>  DNAT    $FW     loc:192.168.10.17 gre   -       - 207.111.163.33
>
>  You need to replace $FW with ''loc''.

The rules were actually "DNAT all loc:192.168.10.17 ..." but your
comment pointed me in the right direction. I now recall using a
loc/net pair of rules while initially testing and that''s when it
worked. After carefully reading the shorewall-rules man page I now
understand why it started failing:

"When all[-] is used either in the SOURCE or DEST column intra-zone
traffic is  not  affected.  When all+[-] is "used, intra-zone traffic
is affected."

Changing the rules from "all" to "all+" fixed the problem,
though I
should probably go back to the loc/net pair to keep things a little
more secure.

>  A more basic question is though, "Why in &^%$ do you want a
loc->loc VPN in
> the first place?"

The VPN case is rather silly but that was just the first service I was
exposing through the firewall so I used it as a test. Next will be a
jabber server where the internal clients are using a public DNS name
and the server is another machine behind the firewall. BIND views are
not an option so I needed to make sure the concept would work.


> >  Try as I might I ended up having to remove routefilter from both of
my
> >  external interfaces because VPN connection attempts from outside were
> >  showing up as martians. I think I did everything that was asked of me
> >  in the documentation to prevent that from happening but if someone
can
> >  see anything in the dumps that might point to why I''m still
seeing
> >  these connections as martians I''d love to be able to turn
that option
> >  back on.
> >
>
>  How could we possibly do that without seeing one of the Martian messages?

I think my problem is I don''t understand why they''re being
seen as
martians simply because I added another public interface to my
configuration, which probably just means I don''t really understand
what defines a martian. I really only mentioned it in case it was
related to my other problems. With everything now functioning properly
it''s more of an educational question so I''m not that worried
about it
anymore, meaning you can just blow me off and I''ll go research on my
own :)

>  That is a ''feature'' of Shorewall 3.4. The Debian
Shorewall maintainer makes
> a 4.0 ''Etch'' repository available at
> http://people.connexer.com/~roberto/debian/ and those packages work well on
> Gutsy.

Good to know :) With the release of hardy so close I''ll probably just
wait for that since it also has 4.0 available but if I end up using
shorewall on one of our etch machines I''ll surely make use of this
repository.



Thank you for all your help!

Brad C