Shorewall users - May 2013 - Masquerade default route for network on internal interface through ipsec built on external/internet interface

Hello,

I am currently attempting to masquerade traffic behind an internal interface
(eth0) destined for the default gateway to go out of a firewall device located
at the other end of an ipsec tunnel.  I have attempted to use the providers
feature to do this, but I can not figure out how to keep the ipsec tunnel up
while having the traffic forwarded.  At this point, the only thing I can think
of is to exclude the far end IP address of the ipsec tunnel and leave everything
else to pass through the other device.  However, I was hoping there was a much
simpler alternative.

Quick overview of network:

[The Internet] <-----> [Corporate HQ - IPSec Device & Firewall
(internal: 10.1.0.1)] <—ipsec—> [The Internet] <—ipsec—> [Remote
Location – eth1] <—shorewall--> [Remote Location – eth0 (10.2.0.1)]
<---> [Internal Network (10.2.0.0/24)]

I went through the shorewall documentation and was unable to find anywhere that
shows this particular example.  I have tried using several configurations in the
masq file, but to no avail:

#INTERFACE SOURCE ADDRESS ...
eth0 192.168.1.0/24 1.1.1.1
#And also tried:
eth0:10.1.0.1 eth0

I am hoping the first example above is the correct format; however, that IP is
on a far-end device.  Also, I do not have an ipsec0 device since I am using
spdadd rules with raccoon that create the static routes of the internal network
at headquarters.

I am certain this is a very simple issue and a solution will be as well, but I
cannot seem to wrap my mind around it.  I have included the shorewall &
kernel versions below for reference.

Shorewall version: 4.4.24.1
Kernel version: 3.4.33-2.24-default (SMP x64)

Thank you for any help.

Ryan

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

On 5/1/13 9:48 AM, "rblake3" <rblake3@hotmail.com> wrote:
> Hello,
>  
> I am currently attempting to masquerade traffic behind an internal
interface
> (eth0) destined for the default gateway to go out of a firewall device
located
> at the other end of an ipsec tunnel.  I have attempted to use the providers
> feature to do this, but I can not figure out how to keep the ipsec tunnel
up
> while having the traffic forwarded.  At this point, the only thing I can
think
> of is to exclude the far end IP address of the ipsec tunnel and leave
> everything else to pass through the other device.  However, I was hoping
there
> was a much simpler alternative.
>  
> Quick overview of network:
>  
> [The Internet] <-----> [Corporate HQ - IPSec Device & Firewall
(internal:
> 10.1.0.1)] <‹ipsec‹> [The Internet] <‹ipsec‹> [Remote Location
­ eth1]
> <‹shorewall--> [Remote Location ­ eth0 (10.2.0.1)] <--->
[Internal Network
> (10.2.0.0/24)]
>  
> I went through the shorewall documentation and was unable to find anywhere
> that shows this particular example.  I have tried using several
configurations
> in the masq file, but to no avail:
>  
> #INTERFACE SOURCE ADDRESS ...
> eth0 192.168.1.0/24 1.1.1.1
That rule says that packets routed out of eth0 with SOURCE IP in
192.168.1.0/24 should have their SOURCE IP changed to
1.1.1.1
> #And also tried:
> eth0:10.1.0.1 eth0
That rule is meaningless.
>  
> I am hoping the first example above is the correct format; however, that IP
is
> on a far-end device.  Also, I do not have an ipsec0 device since I am using
> spdadd rules with raccoon that create the static routes of the internal
> network at headquarters.
>  
> I am certain this is a very simple issue and a solution will be as well,
but I
> cannot seem to wrap my mind around it.  I have included the shorewall &
kernel
> versions below for reference.
>  
> Shorewall version: 4.4.24.1
> Kernel version: 3.4.33-2.24-default (SMP x64)
It might help us if you posted the output of ''shorewall dump''
so we can see
what your gateway configuration looks like. Be sure that ipsec-tools are
installed before you capture the output.

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





------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

On 5/1/13 6:50 PM, "teastep" <teastep@shorewall.net> wrote:

On 5/1/13 9:48 AM, "rblake3" <rblake3@hotmail.com> wrote:
Hello, I am currently attempting to masquerade traffic behind an internal 
interface (eth0) destined for the default gateway to go out of a firewall device
located at the other end of an ipsec tunnel.  I have attempted to use the 
providers feature to do this, but I can not figure out how to keep the ipsec 
tunnel up while having the traffic forwarded.  At this point, the only 
thing I can think of is to exclude the far end IP address of the ipsec tunnel 
and leave everything else to pass through the other device.  However, I was 
hoping there was a much simpler alternative. Quick overview of network: [The
Internet] <-----> [Corporate HQ - IPSec Device & Firewall
(internal: 10.1.0.1)] <—ipsec—> [The Internet] <—ipsec—> [Remote 
Location – eth1] <—shorewall--> [Remote Location – eth0 (10.2.0.1)] 
<---> [Internal Network (10.2.0.0/24)] I went through the shorewall
documentation and was unable to find anywhere
that shows this particular example.  I have tried using several 
configurations in the masq file, but to no avail: #INTERFACE SOURCE ADDRESS
...eth0 192.168.1.0/24 1.1.1.1
That rule says that packets routed out of eth0 with SOURCE IP in 192.168.1.0/24
should have their SOURCE IP changed to 1.1.1.1#And also tried:eth0:10.1.0.1 eth0
That rule is meaningless. 
 I am hoping the first example above is the correct format; however, that IP 
is on a far-end device.  Also, I do not have an ipsec0 device since I am 
using spdadd rules with raccoon that create the static routes of the internal 
network at headquarters. I am certain this is a very simple issue and a solution
will be as well,
but I cannot seem to wrap my mind around it.  I have included the shorewall 
& kernel versions below for reference. Shorewall version: 4.4.24.1Kernel
version: 3.4.33-2.24-default (SMP x64)
It might help us if you posted the output of ''shorewall dump''
so we can see what your gateway configuration looks like. Be sure that
ipsec-tools are installed before you capture the output.
-TomYou do not need a parachute to skydive. You only need a parachute to skydive
twice.

Tom,
Thank you for your reply.  I had a feeling both of the commands would not help,
but I was being hopeful.  At least now I''m certain of what the SOURCE
ADDRESS implies (binding to a specific IP on an interface).  Please see
attached.
Ryan 		 	   		  


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It''s a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

On 5/1/13 6:50 PM, "teastep" <teastep@shorewall.net> wrote:

            On 5/1/13 9:48 AM, "rblake3" <rblake3@hotmail.com>
wrote:

    Hello,

    I am currently attempting to masquerade traffic behind an internal interface
(eth0) destined for the default gateway to go out of a firewall device located
at the other end of an ipsec tunnel.  I have attempted to use the providers
feature to do this, but I can not figure out how to keep the ipsec tunnel up
while having the traffic forwarded.  At this point, the only thing I can think
of is to exclude the far end IP address of the ipsec tunnel and leave everything
else to pass through the other device.  However, I was hoping there was a much
simpler alternative.

    Quick overview of network:

    [The Internet] <-----> [Corporate HQ - IPSec Device & Firewall
(internal: 10.1.0.1)] <—ipsec—> [The Internet] <—ipsec—> [Remote
Location – eth1] <—shorewall--> [Remote Location – eth0 (10.2.0.1)]
<---> [Internal Network (10.2.0.0/24)]

    I went through the shorewall documentation and was unable to find anywhere
that shows this particular example.  I have tried using several configurations
in the masq file, but to no avail:

    #INTERFACE SOURCE ADDRESS ...
    eth0 192.168.1.0/24 1.1.1.1

  That rule says that packets routed out of eth0 with SOURCE IP in
192.168.1.0/24 should have their SOURCE IP changed to 1.1.1.1
    #And also tried:
    eth0:10.1.0.1 eth0

  That rule is meaningless. 


    I am hoping the first example above is the correct format; however, that IP
is on a far-end device.  Also, I do not have an ipsec0 device since I am using
spdadd rules with raccoon that create the static routes of the internal network
at headquarters.

    I am certain this is a very simple issue and a solution will be as well, but
I cannot seem to wrap my mind around it.  I have included the shorewall &
kernel versions below for reference.

    Shorewall version: 4.4.24.1
    Kernel version: 3.4.33-2.24-default (SMP x64)

  It might help us if you posted the output of ''shorewall
dump'' so we can see what your gateway configuration looks like. Be sure
that ipsec-tools are installed before you capture the output.

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

Thank you for your reply.  I had a feeling both of the commands would not help,
but I was being hopeful.  At least now I''m certain of what the SOURCE
ADDRESS implies (binding to a specific IP on an interface).

Please see attached shorewall dump.  Any assistance would be greatly
appreciated.

Ryan



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

On 05/20/2013 11:06 AM, rblake3 wrote:
> Thank you for your reply.  I had a feeling both of the commands would
> not help, but I was being hopeful.  At least now I''m certain of
what the
> SOURCE ADDRESS implies (binding to a specific IP on an interface).
>  
> Please see attached shorewall dump.  Any assistance would be greatly
> appreciated.
Having looked at the dump, I''m lost as to what problem you are trying
to
solve.

-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 \________________________________________________



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

On 05/20/2013 12:13 PM, Tom Eastep wrote:
> On 05/20/2013 11:06 AM, rblake3 wrote:
> 
>> Thank you for your reply.  I had a feeling both of the commands would
>> not help, but I was being hopeful.  At least now I''m certain
of what the
>> SOURCE ADDRESS implies (binding to a specific IP on an interface).
>>  
>> Please see attached shorewall dump.  Any assistance would be greatly
>> appreciated.
> 
> Having looked at the dump, I''m lost as to what problem you are
trying to
> solve.
I do, however, see one obvious IP configuration error:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    inet 10.2.0.1/24 brd 10.2.0.255 scope global eth0 <========    inet
10.2.0.254/24 brd 10.2.0.255 scope global secondary eth0:3

default via 69.161.96.1 dev eth1
69.161.96.0/24 dev eth1  proto kernel  scope link  src 69.161.96.69
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev eth0  scope link
10.1.0.0/24 via 10.2.0.1 dev eth0 <========10.2.0.0/24 dev eth0  proto kernel
scope link  src 10.2.0.1

One of the two marked lines is clearly wrong.

-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 \________________________________________________



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d