Hi all,
I have set up a shorewall 4.4.6 firewall on a Ubuntu 10.04.2 LTS box. There
are two external interfaces (eth-adsl and eth-cable) and one internal (eth-
office). The configuration is according to the Multi-ISP
example on the shorewall site, and works great so far.
zone ''net'':
eth-cable has external IP x.x.x.42 and gateway x.x.x.41
eth-adsl has external IP y.y.y.122 and gateway y.y.y.121
zone ''loc'':
eth-office connects to the internal range 10.0.0.0/24
The next step would be to set up separate VLANs for different parts of
the internal network. For testing puroposes, I have configured a small net
with VLAN ID 99 (interface vlan99, zone ''test''), confined to
the
10.0.99.0/24 subnet.
Communication from the ''test'' zone to the firewall and the
internal ''loc'' zone
works fine, but when I try to contact the outside world, I get martians in the
log and the connection won''t come through.
The following appears when I try to ping the site
''www.apple.com''
(95.101.221.15) from a machine in the ''test'' zone
(10.0.99.99):
Feb 20 18:04:42 io kernel: [ 1418.850318] Shorewall:test2net:ACCEPT:IN=vlan99
OUT=eth-cable SRC=10.0.99.99 DST=95.101.221.15 LEN=84 TOS=0x00 PREC=0x00 TTL=63
ID=32610 PROTO=ICMP TYPE=8 CODE=0 ID=36649 SEQ=0
Feb 20 18:04:43 io kernel: [ 1419.850716] martian source 95.101.221.15 from
x.x.x.42, on dev eth-cable
Feb 20 18:04:43 io kernel: [ 1419.850724] ll header:
00:1b:21:72:95:54:44:58:29:7d:1f:a9:08:00
The strange thing about the martian log entry is that the link layer header
indicates that the packet is coming from the gateway of the cable connection
(MAC 44:58:29:7d:1f:a9) to our ''eth-cable'' interface (MAC
00:1b:21:72:95:54)
but the message above that looks to me like the packet is originating from the
firewall itself (x.x.x.42 to 95.101.221.15). I''m not sure what to make
of
this. Can it be that the packet is routed back to the firewall by the gateway?
But why would that happen?
Some relevant configuration follows below; I will gladly provided additional
information or a dump if desired. If anyone could provide me some pointers
as to what is going wrong here, I''d be very grateful.
Many thanks and best regards,
Dorian
dorian@io:/etc/shorewall$ cat zones
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4
ovpn ipv4
test ipv4
dorian@io:/etc/shorewall$ cat interfaces
#ZONE INTERFACE BROADCAST OPTIONS
net eth-adsl detect routefilter,logmartians
net eth-cable detect routefilter,logmartians
loc eth-office detect dhcp,logmartians
ovpn tun+
test vlan99 detect dhcp
dorian@io:/etc/shorewall$ cat providers
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
COPY
CC-CABLE 1 1 main eth-cable x.x.x.41 track,balance=2
eth-office
CC-ADSL 2 2 main eth-adsl y.y.y.121 track,balance=1
eth-office
dorian@io:/etc/shorewall$ cat masq
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK USER/
# GROUP
eth-adsl 10.0.0.0/16 detect
eth-cable 10.0.0.0/16 detect
dorian@io:/etc/shorewall$ cat policy
#SOURCE DEST POLICY LOG LIMIT: CONNLIMIT:
# LEVEL BURST MASK
loc net ACCEPT
loc fw ACCEPT
ovpn loc ACCEPT
ovpn net ACCEPT
ovpn fw ACCEPT
test fw ACCEPT info
test net ACCEPT info
test loc ACCEPT info
fw test ACCEPT info
fw loc ACCEPT
fw net REJECT
net all DROP
net net DROP info
all all REJECT info
dorian@io:/etc/shorewall$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth-office: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP qlen 1000
link/ether d8:d3:85:b3:a8:ee brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth-office
inet6 fe80::dad3:85ff:feb3:a8ee/64 scope link
valid_lft forever preferred_lft forever
3: eth-adsl: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 100
link/ether 00:1b:21:72:9a:70 brd ff:ff:ff:ff:ff:ff
inet y.y.y.122/30 brd y.y.y.123 scope global eth-adsl
inet6 fe80::21b:21ff:fe72:9a70/64 scope link
valid_lft forever preferred_lft forever
4: eth-cable: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 00:1b:21:72:95:54 brd ff:ff:ff:ff:ff:ff
inet x.x.x.42/30 brd x.x.x.43 scope global eth-cable
inet6 fe80::21b:21ff:fe72:9554/64 scope link
valid_lft forever preferred_lft forever
5: vlan99@eth-office: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
link/ether d8:d3:85:b3:a8:ee brd ff:ff:ff:ff:ff:ff
inet 10.0.99.1/24 brd 10.0.99.0 scope global vlan99
inet6 fe80::dad3:85ff:feb3:a8ee/64 scope link
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 100
link/[65534]
inet 10.0.100.1 peer 10.0.100.2/32 scope global tun0
dorian@io:/etc/shorewall$ ip route show
10.0.100.2 dev tun0 proto kernel scope link src 10.0.100.1
y.y.y.120/30 dev eth-adsl proto kernel scope link src y.y.y.122
x.x.x.40/30 dev eth-cable proto kernel scope link src x.x.x.42
10.0.100.0/24 via 10.0.100.2 dev tun0
10.0.99.0/24 dev vlan99 proto kernel scope link src 10.0.99.1
10.0.0.0/24 dev eth-office proto kernel scope link src 10.0.0.1
default
nexthop via x.x.x.41 dev eth-cable weight 2
nexthop via y.y.y.121 dev eth-adsl weight 1
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
On 2/21/11 6:38 AM, Dorian Kind wrote:> The strange thing about the martian log entry is that the link layer header > indicates that the packet is coming from the gateway of the cable connection > (MAC 44:58:29:7d:1f:a9) to our ''eth-cable'' interface (MAC 00:1b:21:72:95:54) > but the message above that looks to me like the packet is originating from the > firewall itself (x.x.x.42 to 95.101.221.15). I''m not sure what to make of > this. Can it be that the packet is routed back to the firewall by the gateway? > But why would that happen?With this configuration, is the ''loc'' zone still able to communicate with the net? -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 \________________________________________________ ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Yes, from the ''loc'' zone''s point of view, everything still works as before. Thanks & greetings, Dorian On 21.02.2011, at 16:26, Tom Eastep wrote:> On 2/21/11 6:38 AM, Dorian Kind wrote: > >> The strange thing about the martian log entry is that the link layer header >> indicates that the packet is coming from the gateway of the cable connection >> (MAC 44:58:29:7d:1f:a9) to our ''eth-cable'' interface (MAC 00:1b:21:72:95:54) >> but the message above that looks to me like the packet is originating from the >> firewall itself (x.x.x.42 to 95.101.221.15). I''m not sure what to make of >> this. Can it be that the packet is routed back to the firewall by the gateway? >> But why would that happen? > > With this configuration, is the ''loc'' zone still able to communicate > with the net? > > -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 \________________________________________________ > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
On 2/21/11 7:39 AM, Dorian Kind wrote:> Yes, from the ''loc'' zone''s point of view, everything still works as before. >Given that the defintions of the loc and net zones are almost identical, the natural suspicion is that there is a configuration problem with the VLAN. What is the configuration of the physical LAN(s) around the Shorewall box? -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 \________________________________________________ ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
On 2/21/11 10:38 AM, Tom Eastep wrote:> On 2/21/11 7:39 AM, Dorian Kind wrote: >> Yes, from the ''loc'' zone''s point of view, everything still works as before. >> > > Given that the defintions of the loc and net zones are almost identical, > the natural suspicion is that there is a configuration problem with the > VLAN. What is the configuration of the physical LAN(s) around the > Shorewall box? >You might add the ''routefilter'' and ''logmartians'' settings to the vlan99 interface; that might give us another clue. -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 \________________________________________________ ------------------------------------------------------------------------------ Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
Tom, many thanks for your help. I will do as you suggested and try to capture some packets on the external interfaces to gather more information. Best regards, Dorian On 21.02.2011, at 22:27, Tom Eastep wrote:> On 2/21/11 10:38 AM, Tom Eastep wrote: >> On 2/21/11 7:39 AM, Dorian Kind wrote: >>> Yes, from the ''loc'' zone''s point of view, everything still works as before. >>> >> >> Given that the defintions of the loc and net zones are almost identical, >> the natural suspicion is that there is a configuration problem with the >> VLAN. What is the configuration of the physical LAN(s) around the >> Shorewall box? >> > > You might add the ''routefilter'' and ''logmartians'' settings to the vlan99 > interface; that might give us another clue. > > -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 \________________________________________________ > > ------------------------------------------------------------------------------ > Index, Search & Analyze Logs and other IT data in Real-Time with Splunk > Collect, index and harness all the fast moving IT data generated by your > applications, servers and devices whether physical, virtual or in the cloud. > Deliver compliance at lower cost and gain new business insights. > Free Software Download: http://p.sf.net/sfu/splunk-dev2dev_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
Hi,
I was finally able to capture some packets on the external interface. The
following is what happens when I try to establish a http connection to
sony.co.jp from the machine 10.0.99.99 inside the ''test'' zone
(the zone that
contains the VLAN).
x.x.x.42 is the IP of the external interface, 00:1b:21:72:95:54 its MAC address.
44:58:29:7d:1f:a9 is the MAC address of the gateway.
16:34:36.858495 00:1b:21:72:95:54 (oui Unknown) > 44:58:29:7d:1f:a9 (oui
Unknown)
ethertype IPv4 (0x0800), length 78: x.x.x.42.61859 > www.sony.co.jp.www:
Flags [S], seq 2213552875, win 65535, options [mss 1460,nop,wscale
3,nop,nop,TS val 19668929 ecr 0,sackOK,eol], length 0
16:34:37.162154 44:58:29:7d:1f:a9 (oui Unknown) > 00:1b:21:72:95:54 (oui
Unknown)
ethertype IPv4 (0x0800), length 74: www.sony.co.jp.www > x.x.x.42.61859:
Flags [S.], seq 2687494249, ack 2213552876, win 5792, options [mss
1460,sackOK,TS val 3703720903 ecr 19668929,nop,wscale 2], length 0
16:34:37.162209 00:1b:21:72:95:54 (oui Unknown) > 44:58:29:7d:1f:a9 (oui
Unknown)
ethertype IPv4 (0x0800), length 74: www.sony.co.jp.www >
10.0.99.99.61859:
Flags [S.], seq 2687494249, ack 2213552876, win 5792, options [mss
1460,sackOK,TS val 3703720903 ecr 19668929,nop,wscale 2], length 0
To me it looks like there is something seriously wrong with the NAT process, it
appears that the firewall sends out the NATed packet over the wrong interface.
The corresponding log entries follow:
Feb 25 16:34:36 io kernel: [428013.664722] Shorewall:test2net:ACCEPT:IN=vlan99
OUT=eth-cable SRC=10.0.99.99 DST=202.238.100.193 LEN=64 TOS=0x10 PREC=0x00
TTL=63 ID=22135 DF PROTO=TCP SPT=61859 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 25 16:34:37 io kernel: [428014.641743] martian source 202.238.100.193 from
x.x.x.42, on dev eth-cable
Feb 25 16:34:37 io kernel: [428014.641751] ll header:
00:1b:21:72:95:54:44:58:29:7d:1f:a9:08:00
The way I read the link layer header, the log entry corresponds to packet
number 2 above, but the ip source and destination addresses seem to disagree...
I really don''t get what is going on here and would be very grateful for
any
help. If required, I will gladly provide more configuration or capture more
packets.
Thanks and best regards,
Dorian
On 22.02.2011, at 09:41, Dorian Kind wrote:
> Tom,
>
> many thanks for your help. I will do as you suggested and try to capture
> some packets on the external interfaces to gather more information.
>
> Best regards,
> Dorian
>
> On 21.02.2011, at 22:27, Tom Eastep wrote:
>
>> On 2/21/11 10:38 AM, Tom Eastep wrote:
>>> On 2/21/11 7:39 AM, Dorian Kind wrote:
>>>> Yes, from the ''loc'' zone''s point of
view, everything still works as before.
>>>>
>>>
>>> Given that the defintions of the loc and net zones are almost
identical,
>>> the natural suspicion is that there is a configuration problem with
the
>>> VLAN. What is the configuration of the physical LAN(s) around the
>>> Shorewall box?
>>>
>>
>> You might add the ''routefilter'' and
''logmartians'' settings to the vlan99
>> interface; that might give us another clue.
>>
>> -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 \________________________________________________
>>
>>
------------------------------------------------------------------------------
>> Index, Search & Analyze Logs and other IT data in Real-Time with
Splunk
>> Collect, index and harness all the fast moving IT data generated by
your
>> applications, servers and devices whether physical, virtual or in the
cloud.
>> Deliver compliance at lower cost and gain new business insights.
>> Free Software Download:
http://p.sf.net/sfu/splunk-dev2dev_______________________________________________
>> Shorewall-users mailing list
>> Shorewall-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev