Hi all,q
I am using shorewall 4.4.6 on an ipsec road warrior. I am trying to
figure out how to configure so that traffic from a subnet of the road
warrior is SNATted before being encrypted and routed into the ipsec
tunnel. In essence I want to masquerade this subnet into the VPN.
The VPN for this road warrior is the default route, so all traffic from
this road warrior should be directed into the ipsec tunnel. The ipsec
tunnelling is managed by another piece of software so I have zero
ability to reconfigure it and I have zero ability to change the
configuration of the remote end or the policy.
Here''s some of what I have tried so far:
----- interfaces -----
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 - dhcp
kvm virbr0 - dhcp
----- policy -----
#SOURCE DEST POLICY LOG LIMIT: CONNLIMIT:
fw net ACCEPT
net fw DROP
fw kvm ACCEPT
net kvm DROP
fw vpn ACCEPT
kvm vpn ACCEPT
all vpn DROP
vpn fw ACCEPT
vpn all DROP
kvm all ACCEPT
----- zones -----
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
kvm ipv4
vpn ipsec
----- hosts -----
#ZONE HOST(S) OPTIONS
swan eth0:0.0.0.0/0
----- masq -----
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK USER/
virbr0 - 199.10.8.5 - - Yes
where virbr0 is the interface of the subnet I want to masq to the road
warriors assigned IP on the VPN (199.10.8.5).
Looking at the iptables rules, it does not seem to be triggering the
SNAT though:
Chain POSTROUTING (policy ACCEPT 44 packets, 3151 bytes)
pkts bytes target prot opt in out source destination
1 328 virbr0_masq all -- * virbr0 0.0.0.0/0 0.0.0.0/0
Chain virbr0_masq (1 references)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
policy match dir out pol ipsec to:199.10.8.5
As you can see there are no matches in the virbr0_masq chain.
Ideas?
b.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/14/10 9:14 AM, Brian J. Murrell wrote:> Hi all,q > > I am using shorewall 4.4.6 on an ipsec road warrior. I am trying to > figure out how to configure so that traffic from a subnet of the road > warrior is SNATted before being encrypted and routed into the ipsec > tunnel. In essence I want to masquerade this subnet into the VPN. > > The VPN for this road warrior is the default route, so all traffic from > this road warrior should be directed into the ipsec tunnel. The ipsec > tunnelling is managed by another piece of software so I have zero > ability to reconfigure it and I have zero ability to change the > configuration of the remote end or the policy.Near as I can tell, you should simply need to: a) Add an IPSEC tunnel to /etc/shorewall/tunnels. b) Use a standard two-interface configuration; MASQUERADE traffic coming from the kvm subnet. That''s it. Since traffic to/from the default gateway is either all encrypted or all en clair (depending on whether the IPSEC client is active or not), I see no reason to differentiate the two cases. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Wed, 2010-07-14 at 09:36 -0700, Tom Eastep wrote:> > Near as I can tell,As usual Tom, your instincts were right on the mark.> you should simply need to: > > a) Add an IPSEC tunnel to /etc/shorewall/tunnels.Which I did as: #TYPE ZONE GATEWAY GATEWAY # ZONE ipsecnat net 0.0.0.0/0 since I am indeed on at NAT-T configuration here. TBH, I was not sure what, if anything I should put in the GATEWAY ZONE for this configuration.> b) Use a standard two-interface configuration; MASQUERADE traffic coming > from the kvm subnet.Indeed.> That''s it. Since traffic to/from the default gateway is either all > encrypted or all en clair (depending on whether the IPSEC client is > active or not), I see no reason to differentiate the two cases.Fair enough. And it almost, so, very almost works! Here''s a packet received on the kvm interface destined for the VPN: 18:07:41.518736 IP 192.168.122.32.3646 > 10.1.2.3.21: Flags [S], seq 13170946, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 and here is the response: 18:07:54.419302 IP 10.1.2.3.21 > 129.150.48.250.3646: Flags [S.], seq 2706895564, ack 13170947, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0 And here is the conntrack entry for it. ipv4 2 tcp 6 38 SYN_RECV src=192.168.122.32 dst=10.1.2.3 sport=3646 dport=21 packets=1 bytes=64 src=10.1.2.3 dst=199.10.8.5 sport=21 dport=3646 packets=6 bytes=312 mark=0 secmark=0 use=2 But that''s as far as it gets. It doesn''t get sent back through the kvm interface at all. It just disappears at that point. I should note that 199.10.8.5 is not the address of eth0 (the net interface on which the ipsec tunnel is configured) but an eth0:1 configured for ipsec. I dunno if that''s relevant but it is somewhat strange so I thought I would mention it. So the question is, any ideas what might cause Linux to not complete the de-natting and routing of that returned packet back to 192.168.122.32 on the kvm interface? b. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Jul 14, 2010, at 3:18 PM, Brian J. Murrell wrote:> On Wed, 2010-07-14 at 09:36 -0700, Tom Eastep wrote: >> >> Near as I can tell, > > As usual Tom, your instincts were right on the mark. > >> you should simply need to: >> >> a) Add an IPSEC tunnel to /etc/shorewall/tunnels. > > Which I did as: > > #TYPE ZONE GATEWAY GATEWAY > # ZONE > ipsecnat net 0.0.0.0/0 > > since I am indeed on at NAT-T configuration here. TBH, I was not sure > what, if anything I should put in the GATEWAY ZONE for this > configuration. > >> b) Use a standard two-interface configuration; MASQUERADE traffic coming >> from the kvm subnet. > > Indeed. > >> That''s it. Since traffic to/from the default gateway is either all >> encrypted or all en clair (depending on whether the IPSEC client is >> active or not), I see no reason to differentiate the two cases. > > Fair enough. > > And it almost, so, very almost works! > > Here''s a packet received on the kvm interface destined for the VPN: > > 18:07:41.518736 IP 192.168.122.32.3646 > 10.1.2.3.21: Flags [S], seq 13170946, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 > > and here is the response: > > 18:07:54.419302 IP 10.1.2.3.21 > 129.150.48.250.3646: Flags [S.], seq 2706895564, ack 13170947, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0 > > And here is the conntrack entry for it. > > ipv4 2 tcp 6 38 SYN_RECV src=192.168.122.32 dst=10.1.2.3 sport=3646 dport=21 packets=1 bytes=64 src=10.1.2.3 dst=199.10.8.5 sport=21 dport=3646 packets=6 bytes=312 mark=0 secmark=0 use=2 > > But that''s as far as it gets. It doesn''t get sent back through the kvm > interface at all. It just disappears at that point. > > I should note that 199.10.8.5 is not the address of eth0 (the net > interface on which the ipsec tunnel is configured) but an eth0:1 > configured for ipsec. I dunno if that''s relevant but it is somewhat > strange so I thought I would mention it. > > So the question is, any ideas what might cause Linux to not complete the > de-natting and routing of that returned packet back to 192.168.122.32 on > the kvm interface?It doesn''t match the conntrack entry. The conntrack entry expects responses to be addressed to 199.10.8.5 but the response is coming back to 129.150.48.250. What does your /etc/shorewall/masq entry look like? -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 \_______________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Wed, 2010-07-14 at 18:31 -0400, TomEastep wrote:> > It doesn''t match the conntrack entry. The conntrack entry expects responses to be addressed to 199.10.8.5 but the response is coming back to 129.150.48.250.Dmnnit. That was a cut''n''pasto-to-protect-the-innocento. Now that the cat''s out of the bag, the two tcpdump entries and the conntrack entry are: 18:07:41.518736 IP 192.168.122.32.3646 > 10.1.2.3.21: Flags [S], seq 13170946, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 18:07:54.419302 IP 10.1.2.3.21 > 129.150.48.250.3646: Flags [S.], seq 2706895564, ack 13170947, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 2], length 0 ipv4 2 tcp 6 38 SYN_RECV src=192.168.122.32 dst=10.1.2.3 sport=3646 dport=21 packets=1 bytes=64 src=10.1.2.3 dst=129.150.48.250 sport=21 dport=3646 packets=6 bytes=312 mark=0 secmark=0 use=2> What does your /etc/shorewall/masq entry look like?#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth0 192.168.122.0/24 129.150.48.250 And the ADDRESS is because while eth0 is 10.75.22.151, eth0:1 is 129.150.48.250 and is the/my endpoint address of the tunnel. Default routing is done with a: default via 10.75.22.151 dev eth0 src 129.150.48.250 and of course there are ipsec policies that match 129.150.48.250. Cheers, b. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/14/10 7:00 PM, Brian J. Murrell wrote:>> What does your /etc/shorewall/masq entry look like? > > #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK > eth0 192.168.122.0/24 129.150.48.250I specifically said MASQUERADE, not SNAT. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On Wed, 2010-07-14 at 20:06 -0700, Tom Eastep wrote:> > > > #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK > > eth0 192.168.122.0/24 129.150.48.250 > > I specifically said MASQUERADE, not SNAT.Yes, I know. But MASQUERADE results in the source address being re-written to eth0''s interface address (10.75.22.151). This will result in traffic not being routed into the tunnel and instead resulting in the ipsec gateway machine sending back EHOSTUNREACH ICMP errors such as: 23:22:36.144100 IP 10.75.22.151 > 192.168.122.32: ICMP host 148.8.2.1 unreachable, length 72 That''s because there is no route to 148.8.2.1 for packets with the source address of eth0 (10.75.22.151). The only route out is through the ipsec tunnel and the security policy which allows that to happen requires that the source address be 129.150.48.250, which is defined on eth0:1: eth0 Link encap:Ethernet HWaddr 00:51:a7:71:21:f9 inet addr:10.75.22.151 Bcast:10.75.22.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1 RX packets:43367178 errors:0 dropped:0 overruns:0 frame:0 TX packets:84181911 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4016705508 (4.0 GB) TX bytes:2938484768 (2.9 GB) Memory:ffce0000-ffd00000 eth0:1 Link encap:Ethernet HWaddr 00:51:a7:71:21:f9 inet addr:129.150.48.250 Bcast:129.150.255.255 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1 Memory:ffce0000-ffd00000 When the gateway itself routes through the tunnel, it uses the eth0:1 as it source address, presumably via the default route specification: default via 10.75.22.151 dev eth0 src 129.150.48.250 b. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
On 7/14/10 8:31 PM, Brian J. Murrell wrote:> On Wed, 2010-07-14 at 20:06 -0700, Tom Eastep wrote: >>> >>> #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK >>> eth0 192.168.122.0/24 129.150.48.250 >> >> I specifically said MASQUERADE, not SNAT. > > Yes, I know. But MASQUERADE results in the source address being > re-written to eth0''s interface address (10.75.22.151). This will result > in traffic not being routed into the tunnel and instead resulting in the > ipsec gateway machine sending back EHOSTUNREACH ICMP errors such as: > > 23:22:36.144100 IP 10.75.22.151 > 192.168.122.32: ICMP host 148.8.2.1 unreachable, length 72 >Okay -- I''m tired of seeing the onion pealed one layer at a time (complete with bungled obfuscation). Let''s see the output of ''shorewall dump''. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first