Simon Hobson | 1 Jul 12:20 2012
Picon

Re: Is this doable?

Nicolas Riendeau wrote:

>My connection to the Internet is done using an ADSL connection (using
>PPPoE) and I have a static IP.
>
>My ISP also routes to this address a subnet (in a different address range).
>
>I want to be able to assign the subnet IP addresses to servers in my DMZ
>or on my internal network (mostly for outbound traffic in that case).
>
>My normal Internet traffic from my PCs should all appear to come from
>the same IP (and preferrably one in my subnet, not my static IP address).

First off, do you NEED some of your servers on public IPs to be in 
your internal network instead of the DMZ ? If you do, can these be 
dual homed ?

Probably the easiest setup would be to have your DMZ using the public 
subnet, and then route between WAN and DMZ (no NAT involved). 
Obviously your firewall will use up one of your public addresses.
For any devices you need to have present on the internal network, 
then dual home them - ie add a second NIC and connect that to your 
internal network.

When you configure NAT, you can specify which public address is used 
to substitute for your internal IPs. The default (IIRC) would be to 
use the primary Ip of the interface specified, but it can (I think) 
be any IP on the machine.

>I also have another question... Apart from LEAF, are there any other
(Continue reading)

Nicolas Riendeau | 2 Jul 00:10 2012

Re: Is this doable?

Hi!

On 7/1/2012 6:20 AM, Simon Hobson wrote:
> First off, do you NEED some of your servers on public IPs to be in
> your internal network instead of the DMZ ?

Yes... Not doing it would only be a temporary solution that I would like 
to replace with what I described as soon as I could...

Is the problem the way the subnet traffic is routed to me or that I want 
to map those IP to more than one subnet? I know we had/have servers 
mapped like that at work so there must be a way to do it...

(OK the firewall we had/have at work were/are not Shorewall but I would 
be very surprised if it was able to do something Shorewall could not...)

 > If you do, can these be dual homed ?

Dual homing them as in putting two NIC cards in them and put them on 
both the DMZ and internal network? Doesn't that somehow defeat the 
purpose of having the two subnets?

> Probably the easiest setup would be to have your DMZ using the public
> subnet, and then route between WAN and DMZ (no NAT involved).
> Obviously your firewall will use up one of your public addresses.

There would be NAT involved for all the PCs on the internal network 
though, right?

> For any devices you need to have present on the internal network,
(Continue reading)

Simon Hobson | 2 Jul 09:08 2012
Picon

Re: Is this doable?

Nicolas Riendeau wrote:

>  > First off, do you NEED some of your servers on public IPs to be in
>>  your internal network instead of the DMZ ?
>
>Yes... Not doing it would only be a temporary solution that I would like
>to replace with what I described as soon as I could...
>
>Is the problem the way the subnet traffic is routed to me or that I want
>to map those IP to more than one subnet? I know we had/have servers
>mapped like that at work so there must be a way to do it...
>
>(OK the firewall we had/have at work were/are not Shorewall but I would
>be very surprised if it was able to do something Shorewall could not...)

Well it's possible they used private addressing in the DMZ (it's not 
an uncommon thing to do) and port-forward traffic as required. That 
way you can direct any public Ip to any host in any subnet - but you 
still get all the issues relating to using NAT.
Also, at work you may well be using split-horizon DNS, or just using 
different names from the inside, or have the firewall set up to allow 
redirection of traffic from internal addresses to the external 
addresses handled properly (Shorewall can do this, see :
http://shorewall.net/FAQ.htm#DNS-DNAT

>  > If you do, can these be dual homed ?
>
>Dual homing them as in putting two NIC cards in them and put them on
>both the DMZ and internal network? Doesn't that somehow defeat the
>purpose of having the two subnets?
(Continue reading)

Anshuman Aggarwal | 4 Jul 12:33 2012
Picon

Excluding by group in shore wall rules

Hi,
 I have the following rules to transparently redirect all port 80
traffic (including that originating on the firewall itself)  to my
firewall+proxy server while not going into a redirect loop for the
processes running on the server itself (by excluding using !:group).
However, a local process running on the server is also seeing its
traffic redirected to the proxy resulting in a forwarding loop?

Any ideas, or what are the requirements for the exclusion by group?
REDIRECT        loc             33128   tcp     www     -       !10.0.0.0/28
REDIRECT        $FW             33128   tcp     www     -
!10.0.0.0/24    -       !:proxy

Thanks,
Anshuman

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Tom Eastep | 4 Jul 16:23 2012
Picon

Re: Excluding by group in shore wall rules

On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote:
> Hi,
>   I have the following rules to transparently redirect all port 80
> traffic (including that originating on the firewall itself)  to my
> firewall+proxy server while not going into a redirect loop for the
> processes running on the server itself (by excluding using !:group).
> However, a local process running on the server is also seeing its
> traffic redirected to the proxy resulting in a forwarding loop?
>
> Any ideas, or what are the requirements for the exclusion by group?
> REDIRECT        loc             33128   tcp     www     -       !10.0.0.0/28
> REDIRECT        $FW             33128   tcp     www     -
> !10.0.0.0/24    -       !:proxy

When I try that, I don't get a forwarding loop; but it doesn't work and 
I'm seeing this:

Jul  4 07:09:19 gateway fw-net REJECT  IN= OUT=eth1 SRC=70.90.191.121 
DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP 
SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0

Note that it is trying to route packets to the local system 
(DST=127.0.0.1) out of eth1. The ip stack doesn't seem to be re-routing 
the packet after NAT is applied. This is on Debian Squeeze.

-Tom
--

-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
(Continue reading)

Tom Eastep | 4 Jul 20:25 2012
Picon

Re: Excluding by group in shore wall rules

On 7/4/12 7:23 AM, "Tom Eastep" <teastep <at> shorewall.net> wrote:

>On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote:
>> Hi,
>>   I have the following rules to transparently redirect all port 80
>> traffic (including that originating on the firewall itself)  to my
>> firewall+proxy server while not going into a redirect loop for the
>> processes running on the server itself (by excluding using !:group).
>> However, a local process running on the server is also seeing its
>> traffic redirected to the proxy resulting in a forwarding loop?
>>
>> Any ideas, or what are the requirements for the exclusion by group?
>> REDIRECT        loc             33128   tcp     www     -
>>!10.0.0.0/28
>> REDIRECT        $FW             33128   tcp     www     -
>> !10.0.0.0/24    -       !:proxy
>
>When I try that, I don't get a forwarding loop; but it doesn't work and
>I'm seeing this:
>
>Jul  4 07:09:19 gateway fw-net REJECT  IN= OUT=eth1 SRC=70.90.191.121
>DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP
>SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0
>
>Note that it is trying to route packets to the local system
>(DST=127.0.0.1) out of eth1. The ip stack doesn't seem to be re-routing
>the packet after NAT is applied. This is on Debian Squeeze.

However, if I allow tcp port 80 *for all users* fw->net, then it works and
still goes through the proxy (without loops).
(Continue reading)

Anshuman Aggarwal | 4 Jul 20:35 2012
Picon

Re: Excluding by group in shore wall rules

I have allowed port 80 to all users and the redirect works.

Problem is I have a apt-cacher-ng proxy process which is run as
apt-cacher-ng with group apt-cacher-ng which proxies the debian
packages and which I want to access port 80 directly. For this process
to be excluded, I made its primary group 'proxy' and changed the init
script so it launched the process with the group as 'proxy' . still
the redirect loop is happening for this apt-cacher-ng process

Thanks,
Anshuman
On 4 July 2012 19:53, Tom Eastep <teastep <at> shorewall.net> wrote:
> On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote:
>> Hi,
>>   I have the following rules to transparently redirect all port 80
>> traffic (including that originating on the firewall itself)  to my
>> firewall+proxy server while not going into a redirect loop for the
>> processes running on the server itself (by excluding using !:group).
>> However, a local process running on the server is also seeing its
>> traffic redirected to the proxy resulting in a forwarding loop?
>>
>> Any ideas, or what are the requirements for the exclusion by group?
>> REDIRECT        loc             33128   tcp     www     -       !10.0.0.0/28
>> REDIRECT        $FW             33128   tcp     www     -
>> !10.0.0.0/24    -       !:proxy
>
> When I try that, I don't get a forwarding loop; but it doesn't work and
> I'm seeing this:
>
> Jul  4 07:09:19 gateway fw-net REJECT  IN= OUT=eth1 SRC=70.90.191.121
(Continue reading)

Tom Eastep | 4 Jul 20:39 2012
Picon

Re: Excluding by group in shore wall rules

On 7/4/12 11:25 AM, "Tom Eastep" <teastep <at> shorewall.net> wrote:

>On 7/4/12 7:23 AM, "Tom Eastep" <teastep <at> shorewall.net> wrote:
>
>>When I try that, I don't get a forwarding loop; but it doesn't work and
>>I'm seeing this:
>>
>>Jul  4 07:09:19 gateway fw-net REJECT  IN= OUT=eth1 SRC=70.90.191.121
>>DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP
>>SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0
>>
>>Note that it is trying to route packets to the local system
>>(DST=127.0.0.1) out of eth1. The ip stack doesn't seem to be re-routing
>>the packet after NAT is applied. This is on Debian Squeeze.
>
>However, if I allow tcp port 80 *for all users* fw->net, then it works and
>still goes through the proxy (without loops).

As in:

	Web(ACCEPT)     fw net           -   -  -		-		-  :proxy
	Web(REDIRECT-)  fw			3128          tcp	80			-		-		-      !:proxy
	ACCEPT:info(uid	fw			net:127.0.0.1

-Tom
You do not need a parachute to skydive. You only need a parachute to
skydive twice.

------------------------------------------------------------------------------
Live Security Virtual Conference
(Continue reading)

Tom Eastep | 4 Jul 20:50 2012
Picon

Re: Excluding by group in shore wall rules

On 7/4/12 11:35 AM, "Anshuman Aggarwal" <anshuman.aggarwal <at> gmail.com>
wrote:

>I have allowed port 80 to all users and the redirect works.
>
>Problem is I have a apt-cacher-ng proxy process which is run as
>apt-cacher-ng with group apt-cacher-ng which proxies the debian
>packages and which I want to access port 80 directly. For this process
>to be excluded, I made its primary group 'proxy' and changed the init
>script so it launched the process with the group as 'proxy' . still
>the redirect loop is happening for this apt-cacher-ng process

Then you are doing something different than I'm doing (besides running
apt-cacher-ng rather than Squid3).

-Tom
You do not need a parachute to skydive. You only need a parachute to
skydive twice.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Tom Eastep | 4 Jul 23:38 2012
Picon

Re: Excluding by group in shore wall rules

On 7/4/12 11:50 AM, Tom Eastep wrote:
> On 7/4/12 11:35 AM, "Anshuman Aggarwal" <anshuman.aggarwal <at> gmail.com>
> wrote:
> 
>> I have allowed port 80 to all users and the redirect works.
>>
>> Problem is I have a apt-cacher-ng proxy process which is run as
>> apt-cacher-ng with group apt-cacher-ng which proxies the debian
>> packages and which I want to access port 80 directly. For this process
>> to be excluded, I made its primary group 'proxy' and changed the init
>> script so it launched the process with the group as 'proxy' . still
>> the redirect loop is happening for this apt-cacher-ng process
> 
> 
> Then you are doing something different than I'm doing (besides running
> apt-cacher-ng rather than Squid3).

If you send us the output of 'shorewall dump' as a compressed
attachment, we'll take a look.

-Tom
--

-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

------------------------------------------------------------------------------
(Continue reading)


Gmane