Bill Shirley | 8 Sep 21:10 2015

Shorewall6: Documentation

http://shorewall.net/manpages6/shorewall6-mangle.html
has TTL but Shorewall6 won't let you use it:
Checking /etc/shorewall6/mangle...
    ERROR: TTL is not supported in IPv6 - use HL instead /etc/shorewall6/mangle (line 29)

shorewall6 check works after changing TTL to HL.

HL is not documented though.

Thanks for all you do,
Bill

------------------------------------------------------------------------------
Vieri Di Paola | 8 Sep 15:05 2015
Picon

providers track option and rtrules

Hi,

My goal is to have 2 NICs associated to 2 providers for specific private IP address ranges (eg. all traffic
to/from 10.215.224.0/20 should go through these two providers).
Another NIC allows access to Internet and that should be the default route.
The other NIC of course is connected to the local network.

At the moment I don't want to load-balance outgoing connections. I understand that I can force outbound
connections with rtrules:

10.215.247.194          10.215.236.221          IBS             11000
-                       10.215.224.0/20         CAIB            11001

So connections from "lan" src 10.215.247.194 to destination 10.215.236.221 will imperatively go via IBS provider.
All other connections to 10.215.224.0/20 will go through CAIB provider.

Now, suppose "providers" contains the following:

CAIB    1       1       -       $IF_CAIB        $ADDR_GW_CAIB   loose,track
IBS     2       2       -       $IF_IBS         $ADDR_GW_IBS    loose,track

and the remote router behind IBS and CAIB decides to send a packet from 10.215.236.221 to 10.215.247.194
via the CAIB provider (new connection) then where will shorewall reply?
If the "track" option is specified in "providers" then the packet will be MARKed with 1 in this case and I
guess that it should go back out the CAIB provider DESPITE the rtrule shown above, right?

However, "shorewall show routing" displays among other things:

Routing Rules

(Continue reading)

shorewall-users-bounces | 8 Sep 07:33 2015
Picon
Picon

[SPAM]

On 9/6/2015 1:36 PM, Nerijus Baliunas wrote:
> On Sun, 6 Sep 2015 12:38:45 +0300 Nerijus Baliunas <nerijus <at> users.sourceforge.net> wrote:
> 
>> Now I changed direction back again. The broadcast packet has Dst IP 192.168.1.255 and MAC 00:1b:21:0e:xx:xx.
>> It is the MAC of my local ethernet interface. How do I make it ff:ff:ff:ff:ff:ff?
>>
>> For the reference, the shorewall rule is:
>> DNAT    loc     loc:192.168.1.255       udp     27036   27036   5.20.215.255
> 
> I did a packet dump after launching Steam and changed the MAC:
> tcpdump -w dump.pcap -i br1 port 27036
> tcprewrite --infile=dump.pcap --outfile=temp1.pcap --dstipmap=0.0.0.0/0:192.168.1.255 --enet-dmac=FF:FF:FF:FF:FF:FF
> tcprewrite --infile=temp1.pcap --outfile=final.pcap --fixcsum
> 
> On Mon, 31 Aug 2015 23:22:11 +0300 Nerijus Baliunas <nerijus <at> users.sourceforge.net> wrote:
> 
>> I suspect that if the Steam client on another PC sees at least one broadcast,
>> it will contact the sending PC directly and they will see each other.
> 
> I was right - after replaying the network traffic:
> tcpreplay --intf1=br1 final.pcap
> both Steam clients connected.
> 
> Is it possible to make destination MAC FF:FF:FF:FF:FF:FF so that I don't need to run tcpreplay
> every time?

Shorewall does not include support for manipulation of MAC addresses.

-Tom
--

-- 
(Continue reading)

Bill Shirley | 7 Sep 15:19 2015

Shorewall6: Mr. Mangle not happy

I've run into a problem with using SAVE(0x3ffff) and RESTORE(0x3ffff) in the mangle table:
[0:root <at> elmo dhcp]$ shorewall6 check
Checking...
Processing /etc/shorewall6/params ...
Processing /etc/shorewall6/shorewall6.conf...
Loading Modules...
Checking /etc/shorewall6/zones...
Checking /etc/shorewall6/interfaces...
Checking /etc/shorewall6/hosts...
Determining Hosts in Zones...
Locating Action Files...
Checking /etc/shorewall6/policy...
Adding rules for DHCP
Checking TCP Flags filtering...
Checking Accept Routing Advertisements...
Checking /etc/shorewall6/mangle...
    ERROR: Mark value (0x3ff00) too large /etc/shorewall6/mangle (line 106)

Line 106 is a RESTORE:
RESTORE($CONNMASK) $FW                             -                       all     { test=0/$CONNMASK }

It's the RESTORE operand that's failing.  If I code 0xff for the test operand it still fails.  However, if I
code 0xff for RESTORE it's happy.  Also note, it's a mask; not a mark.

[2:root <at> elmo shorewall6]$ rpm -q shorewall6
shorewall6-4.6.11.1-2.fc22.noarch

/etc/shorewall6/params:
CONNMASK=0x3ff00
IPSEC_MARK=0x10000
(Continue reading)

Ob Noxious | 6 Sep 12:17 2015
Picon

First experience (next)

Hi,

Please disregard my previous comment about the invalid TCP flags FIN,RST and PSH,FIN passing through "tcpflags" chain. They indeed passthrough but are blocked later by the "?SECTION INVALID" of the "rules" file. They simply were silently dropped because INVALID_LOG_LEVEL was unset in shorewall.conf :-)

About this setting, and more generally, all *_LOG_LEVEL in shorewall.conf, it would be very nice to be able to use the extended format for specifying the log level. I'm starting to really enjoy this new and highly flexible format :-)

ex: "INVALID_LOG_LEVEL=info:,Invalid" would produce (in logs) the slightly more useful "xxx:_net-fw:Invalid:IN=eth0" rather than the default "xxx:_net-fw::IN=eth0" which does not really gives information.

Thankfully I was able to workaround the limitation with a line in "rules" file : LOG:info:,Invalid { source=all dest=all }

I'm really enjoying Shorewall for now. It's a bit "complex" for the newcomer but highly configurable, to an impressive level I must say.

--
ObNox
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Ob Noxious | 6 Sep 08:52 2015
Picon

First experience

Hi,

I'm testing Shorewall and it plays nice. I'm replacing my own home made IPTables/NetFilter friendly wrapper I wrote more than a decade ago which works perfectly well but lacks some features now like really ultra fine grained special configurations support. I don't see the real need to rewrite it given the tremendous amount of work done in Shorewall.

I have a test setup to play with in the usual shape (net + dmz) and using Shorewall 4.6.11.2

Here are my findings and questions:

- Documentation says that SHOREWALL_SHELL defaults to "/bin/sh" in /etc/shorewall/shorewall.conf but if it's not defined, the compiler complains with a warning:
Use of uninitialized value $Shorewall::Compiler::config{"SHOREWALL_SHELL"} in concatenation (.) or string at /usr/share/shorewall/Shorewall/Compiler.pm line 95.

- There is the highly convenient [ACTION]:loglevel:tag,disposition but it's very hard to find it in the documentation. I remember seeing it once but when I was searching for it again, I had to use my memory to reproduce it as there was no way to find it again.

- I tried to "Ping Flood" protect testhost to see how it would react. My first approach was in "rules" files :

?SECTION NEW
Ping(ACCEPT)  { source=all dest=all rate=1/sec }

Then from another host : ping -i 0.2 testhost (or "ping -f testhost" as root) but it did work, all packets passed through, 0% packet loss. New try with

?SECTION NEW
Ping(ACCEPT)  { source=all dest=all rate=1/sec }
Ping(DROP):info:,PingFlood  { source=all dest=all }

Again, not working as expected, 0% packet loss on the pinging host side.

Examining the NetFilter chains (shorewall show) proved that INPUT -> net-fw -> 3rd rule "ACCEPT cstate ESTABLISHED" drank all the packets. This explains why Ping(ACCEPT) {...} was only reached once, hence not triggering the rate limit!

Finally, I moved these two rules to "?SECTION ALL" and now it works as expected.

Is this the right way to do it? Is there a more "elegant" way of performing the same action like in one line only using another method?

- I submitted a bunch of TCP packets with invalid flags to be caught by the "tcpflags" chains and some of them made it through like FIN,RST PSH,FIN. Is there a special reason?

- About the "tcpflags" chain, why not put it in the PREROUTING raw or mangle table which is reach first wherever the packet is destined to? "tcpflags" filters unwanted traffic so it'll be beneficial for all zones by dropping packets at early stage and would avoid duplication by referencing it in so many chains.

- Any plans to support the SYNPROXY introduced recently? :-)

- Shorewall is meant to secure entire networks ranking from the small home setup to quite large/complex setups. Yet, I don't see it managing "sys/module/nf_conntrack/parameters/hashsize" and "/proc/sys/net/netfilter/nf_conntrack_max" which are very important for connection tracking with lots of hosts. Shouldn't Shorewall provide a helper for that or at least mention it in the docs?

That's it for now :-)

--
ObNox
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Vieri Di Paola | 4 Sep 14:49 2015
Picon

load balance only from one host

Hi,

I'm trying to understand how to correctly configure load balancing and policy-based routing within shorewall.

I have the typical local (lan) and internet (wan) zones.

I also have 2 "providers" (not ISPs, just remote private networks) as defined here:

CAIB    1       1       -       $IF_CAIB        $ADDR_GW_CAIB   loose,track
IBS     2       2       -       $IF_IBS         $ADDR_GW_IBS    loose,track

My "main" routing table contains rules such as:

10.215.224.0/20 via $ADDR_GW_CAIB dev $IF_CAIB

I also defined this in "rtrules":

10.215.247.194          10.215.236.221          IBS             300

So if I do a traceroute from 10.215.247.194 to 10.215.236.221 then the packets are going out $IF_IBS as expected.
Any other source to that destination goes out $IF_CAIB.

However, now I'd like to do something else. I'd like to load balance outgoing traffic from source IP 10.215.247.194 ONLY to both CAIB and IBS providers.
In other words, destination IP 10.215.236.221 is accessible via both providers CAIB and IBS, with connection tracking on the destination router.

How can I configure shorewall to load-balance connections from 10.215.247.194 to 10.215.236.221 via CAIB and IBS providers?

My first guess would be to remove the above "rtrules" entry and add the following to the "providers" file:

CAIB    1       1       -       $IF_CAIB        $ADDR_GW_CAIB   loose,track,balance
IBS     2       2       -       $IF_IBS         $ADDR_GW_IBS    loose,track,balance

However, this should load balance all connections, not JUST connections with source IP 10.215.247.194, right?
Again, is it possible to load-balance from only one source IP address?

Also, how can I correctly configure the routing tables?
Given the above example, should I remove 10.215.224.0/20 from the "main" routing table and add the following to "routes"?

CAIB                    10.215.224.0/20         $ADDR_GW_CAIB   $IF_CAIB
IBS                     10.215.224.0/20         $ADDR_GW_IBS    $IF_IBS

Please find attached shorewall dump.

Thanks,

Vieri


Attachment (dump.gz): application/gzip, 42 KiB
------------------------------------------------------------------------------
------------------------------------------------------------------------------
ricky gutierrez | 2 Sep 22:07 2015
Picon

Shorewall module Sip

Hi list , I am presenting some problems with a server sip, what I have
behind a firewall shorewall, and when I call from remote extensions do
not have audio, I open the SIP and RTP ports, but I can not make it
work, if I remove the shorewall and add a route I work with iptables.

shorewall make a DNAT to ip of my server VOIP ,

shorewall have a two network cards WAN - LAN

LAN :192.168.100.4
VOIP: 192.168.100.5

 This log is an external call to an internal

ep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2 13:52:54 localhost kernel: Shorewall:loc-net:REJECT:IN=eth1
OUT=eth0 MAC=00:0c:29:e6:a7:8e:00:0c:29:8e:1f:8e:08:00
SRC=192.168.100.5 DST=172.16.8.179 LEN=204 TOS=0x18 PREC=0xA0 TTL=63
ID=0 DF PROTO=UDP SPT=16008 DPT=11956 LEN=184
Sep  2

I tried this guide but without success

http://www.shorewall.net/4.2/FAQ.htm#faq77

verion of shorewall is shorewall-4.6.4.1-1.el7.noarch

regardss

--

-- 
rickygm

http://gnuforever.homelinux.com

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
Nerijus Baliunas | 31 Aug 00:55 2015
Picon
Picon

DNAT broadcast

Hello,

An application (steam) uses WAN interface to send broadcasts. I set up
network namespaces so that steam does not see WAN interface:

ip netns add steam
ip link add veth0 type veth peer name veth1
brctl addif br1 veth1
ip link set veth0 netns steam
ip netns exec steam ip link set dev veth0 up
ip link set dev veth1 up
ip netns exec steam ip link set lo up
ip netns exec steam ip addr add 192.168.1.11/24 broadcast 192.168.1.255 dev veth0
ip netns exec steam ip route add default via 192.168.1.10

Before using namespaces steam sent broadcast packets via WAN interface:
23596  73.037108 5.20.215.xx -> 5.20.215.255 UDP 135 Source port: 27036  Destination port: 27036

Now it sends via LAN, but to the wrong broadcast address:
252   3.250078 192.168.1.11 -> 5.20.215.255 UDP 136 Source port: 27036  Destination port: 27036

It should send broadcasts to 192.168.1.255 and not 5.20.215.255.
I don't know how steam knows my WAN broadcast address if I use namespaces.

A question - is it possible to redirect broadcast destined to 5.20.215.255 to 192.168.1.255?
I quickly tried to use the following rule unsuccessfully:
DNAT   loc     loc:192.168.1.255       udp     27036   27036   5.20.215.255

Regards,
Nerijus

------------------------------------------------------------------------------
hitesh menghani | 26 Aug 13:18 2015
Picon

shorewall6 failed to start

Whenever I am using IPv6 range in shorewall6/hosts file, it fails to restart and throwing Invalid IPv6 Address ([1:2:3::ffff:ffff:ffff:fffc

For more information:
shorewall6 zone file:
WAN ipv6
DMZ ipv6
fwall firewall
LAN:WAN ipv6

shorewall6 interface file:
WAN eth0 routeback

shorewall6 interface file:
LAN eth0:[1:2:3::ffff:ffff:ffff:fffc-1:2:3::ffff:ffff:ffff:fffd,1:2:3::ffff:ffff:ffff:ff11-1:2:3::ffff:ffff:ffff:ff22]

Also, I checked installed ip6tables support iprange.

Am I doing it wrong? Or is there syntactical mistake in my configuration file.
Expecting reply.

Thanks,
Hitesh
 

------------------------------------------------------------------------------
------------------------------------------------------------------------------
Vieri Di Paola | 25 Aug 09:39 2015
Picon

nested zones

Hi,

I'm not sure I correclty understand how nested zones work in Shorewall.

My zones file includes these 2 zones:
caib        ipv4
ibs:caib        ipv4

My policy file is as shown below regarding the ibs child zone alone ("caib ibs CONTINUE" doesn't make much sense, does it?):

# grep ibs policy
lan     ibs     CONTINUE        info
wan     ibs     CONTINUE        info
dmz     ibs     CONTINUE        info
ibs     all     CONTINUE        info
caib    ibs     CONTINUE        info
road    ibs     CONTINUE        info
vpn1    ibs     CONTINUE        info
vpn2    ibs     CONTINUE        info
ovpn    ibs     CONTINUE        info
$FW     ibs     CONTINUE        info

As I understand it, client connection requests between eg. the "lan" zone and the "ibs" zone should first be processed under the "lan/caib" rules and if there is no match then the connection request should be treated under "lan/ibs" rules.
Let's say I have allowed all traffic from lan:10.215.144.48 to caib:10.215.137.241 (ignore routing table) but I haven't written any specific lan to ibs rules.
Shouldn't a ping from lan:10.215.144.48 to ibs:10.215.137.241 be allowed?

I'm attaching a compressed shorewall dump file while trying to ping 10.215.137.241 from 10.215.144.48.

I'm getting the following in the log:

lan-ibs:CONTINUE:IN=enp5s3 OUT=enp5s0 SRC=10.215.144.48 DST=10.215.137.241 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=9918 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=96
FORWARD:REJECT:IN=enp5s3 OUT=enp5s0 SRC=10.215.144.48 DST=10.215.137.241 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=9918 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=96

Thanks for explaining how nested zones work because I'm sure I got it wrong.

Vieri

Attachment (dump.gz): application/gzip, 404 KiB
------------------------------------------------------------------------------
------------------------------------------------------------------------------

Gmane