Re: [Shorewall-users] mangle and network mask

[Bill Shirley]

Two observations:
1) there are some PC viruses that change the DNS server addresses on the PC
    so that they can intercept a lookup and return their own reply. So, when you
    go to www.my-bank.com you actually are pointed to a malicious server.
    In my rules, I redirect all DNS queries to my own server that is running on 
the
    firewall:
?SECTION NEW
# =
# == Local Restrictions ===
# =
?COMMENT domain
REDIRECT    lan        domain        tcp,udp    domain     # use this server 
for DNS
REDIRECT    dmz        domain        tcp,udp    domain     # use this server 
for DNS
    This way I can insure no query is hijacked.  I implemented these rules when 
we
    found a PC that was getting its lease info (address, gateway, DNS servers, 
etc)
    from our own DHCP, but was using two unknown DNS servers.

2) With multiple ISPs, it is best to do the DNS lookup thru the same provider 
that the
    actual traffic will go.  Many content delivery networks (CDN) will have 
multiple
    servers and the DNS query response will return an answer with the least 
hops.
    I know predicting the actual ISP for traffic may be a difficult task, but 
your efforts
    here would be better that random.

HTH,
Bill

On 9/29/2017 4:54 PM, Vieri Di Paola via Shorewall-users wrote:


From: Tom Eastep 

It is the *next to the last* rule that is causing the problem.


OK, so my problem is that I wrote the following in my mangle file:

MARK(1-3):P 0.0.0.0/0   0.0.0.0/0   tcp,udp 53

and it translated to:

Chain tcpre

[...]
7784 6738K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 MARK xset 0x1/0xff
7783 6764K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 packet 1 MARK xset 0x2/0xff
7783 6623K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 packet 2 MARK xset 0x3/0xff

I erroneously thought that I could "balance" DNS traffic among the first 3 
providers.

It can't be done here, right?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall 5.1.7.2

[Tom Eastep]

Shorewall 5.1.7.2 is  now available for download.

It corrects a couple of potentially serious problems that affect many
resent releases:

1)  Previously during the opening of a configuration file, if SELinux
denied the "getattr" (stat) request, then the compiler would skip
processing of the file as if it did not exist. Now, if "getattr"
fails for any reason other than that the file does not exist, an
error is raised.

   ERROR: Unable to access : 

2)  Previously, when a range was passed to the MARK() action (mangle
file), any specified protocol, port and time restrictions were
ignored. Now these elements are included in the rule.

Thank you for using Shorewall,

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Tom Eastep]

On 09/29/2017 01:54 PM, Vieri Di Paola via Shorewall-users wrote:
> 
> 
> From: Tom Eastep 
>>
>> It is the *next to the last* rule that is causing the problem.
> 
> 
> OK, so my problem is that I wrote the following in my mangle file:
> 
> MARK(1-3):P   0.0.0.0/0   0.0.0.0/0   tcp,udp 53
> 
> and it translated to:
> 
> Chain tcpre
> 
> [...]
> 7784 6738K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0  
>   statistic mode nth every 3 MARK xset 0x1/0xff
> 7783 6764K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0  
>   statistic mode nth every 3 packet 1 MARK xset 0x2/0xff
> 7783 6623K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0  
>   statistic mode nth every 3 packet 2 MARK xset 0x3/0xff
> 
> I erroneously thought that I could "balance" DNS traffic among the first 3 
> providers.
> 
> It can't be done here, right?

It appears that the entry is not being translated correctly, as it is
missing the protocols and port. So take it out for now.

-Tom
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
> 


-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Vieri Di Paola via Shorewall-users]

From: Tom Eastep 
>
> It is the *next to the last* rule that is causing the problem.


OK, so my problem is that I wrote the following in my mangle file:

MARK(1-3):P 0.0.0.0/0   0.0.0.0/0   tcp,udp 53

and it translated to:

Chain tcpre

[...]
7784 6738K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 MARK xset 0x1/0xff
7783 6764K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 packet 1 MARK xset 0x2/0xff
7783 6623K MARK   all  --  *  *   0.0.0.0/00.0.0.0/0
statistic mode nth every 3 packet 2 MARK xset 0x3/0xff

I erroneously thought that I could "balance" DNS traffic among the first 3 
providers.

It can't be done here, right?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT+SNAT+FTP Helper Problem

[Tom Eastep]

On 09/29/2017 12:41 PM, Juha Leinonen wrote:
> Yes, in this case adding rule to SNAT file to change source IP of packet
> traveling from Internet to local LAN. 
> 
>

I have reproduced the problem and it does not appear to be a Shorewall
issue. Will file a bug report.

Regards,
-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT+SNAT+FTP Helper Problem

[Juha Leinonen]

Yes, in this case adding rule to SNAT file to change source IP of packet
traveling from Internet to local LAN.

-Juha

29.9.2017 7.20 ip. "Tom Eastep"  kirjoitti:

On 09/29/2017 04:29 AM, Juha Leinonen wrote:
> Hi,
>
> I'm running Debian 9.1 with
> Linux 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux
> Shorewall version 5.0.15.6
>
> And I'm unable to get DNAT + SNAT + FTP helper combination working.
>
> DNAT + FTP Helper works, but when trying to get source IP address also
> changed traffic never passes to inside interface.
> Also combination DNAT + SNAT works, but then passive FTP doesn't work as
> conntrack is not following packets.
>
> Have anyone by any change happened to stumble into this? This has been
> working flawlessy with old 3.16 kernel and shorewall 4.x.
>

Just to clarify, I assume that when you add SNAT, you are adding an SNAT
rule that changes the source IP on packets leaving the local interface?

-Tom
--
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] My shorewall config

[Tom Eastep]

On 09/29/2017 08:25 AM, Rommel Rodriguez Toirac wrote:
> 
> 
> El sept. 28, 2017 11:23 AM, Tom Eastep  escribió:
> 
> On 09/25/2017 09:09 AM, Rommel Rodriguez Toirac wrote:
> >  Hello;
> > I have configured a network with shorewall as firewall in a host
> bastion
> > mode and I want to configure a DMZ.
> >  This is a little view of what I have done.
> > 
> >  I declared three zones in my network; in the 192.168.41.0/24 IP
> range
> > are my internal network (the shorewall firewall use the
> 172.16.120.1 IP
> > to masquerade it) and in the 172.16.120.0/24 my external. The DMZ
> are in
> > 192.168.14.0/24 IP range.
> > 
> >  The services of email and web browser depend of a first level
> network
> > that are installed in other center (center offices); I mean, there
> are a
> > central email server for all in and out email and a central proxy for
> > access to web. For that I have an asigment IP for my email and proxy
> > servers that are authorized.
> > 
> >  My network serve to a thirth level network (municipal offices).
> email
> > (pop3me of the services
> > used form then.
> >
> >  This is my working around to try the DMZ config.
> > 
> >  - Declared the zones and the interfaces. Four zones: for the
> internal
> > network (loc), for the external network (net), for the DMZ network
> (dmz)
> > and for the firewall it seft (fw). The interfaces are assignet to the
> > corresponding zones using the interfaces identifications.
> > 
> > fw  firewall
> > net ipv4
> > loc ipv4
> > dmz ipv4
> >
> > net enp4s1  tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
> > loc enp5s0  tcpflags,nosmurfs,routefilter,logmartians
> > dmz enp7s0  tcpflags,nosmurfs,routefilter,logmartians
> >
> > 
> >  - Configure the policy. The must simple: allow from the firewall
> access
> > to every network; from the internal network can access to the
> external
> > network and to the DMZ; from the DMZ can access to the local or
> internal
> > network and to the external. From the external network is not allowed
> > the access, this will be controlled for the firewall rules. If
> something
> > is needed from the internal network and from the DMZ network to the
> > firewall, it will be controlled from the firewall rules
> >   In the last places if something is missing it will be rejected.
> > 
> > fw  net ACCEPT  info
> > fw  dmz ACCEPT  info
> > fw  loc ACCEPT  info
> > loc net ACCEPT  info
> > loc dmz ACCEPT  info
> > dmz loc ACCEPT  info
> > dmz net ACCEPT  info
> 
> The above policies make all of the ACCEPT rules in your rules file
> unnecessary.
> 
> > net all DROP    info
> > all all REJECT  info
> >
> >  - Rules. Here declared the service needed from my users (in my
> internal
> > network and in the municipal offices) for example the access to the
> > instant messages service, to the email services, the access to the
> DNS
> > services and consult to the external DNS from my network
> > 
> > ?SECTION ALL
> > ?SECTION ESTABLISHED
> > ?SECTION RELATED
> > ?SECTION INVALID
> > ?SECTION UNTRACKED
> > ?SECTION NEW
> >
> > DNS(DNAT):info    net  dmz:192.168.14.12
> > FTP(DNAT):info    net  dmz:192.168.14.13
> > Squid(DNAT):info    net dmz:192.168.14.18
> > DNAT:info   net dmz:192.168.14.15tcp5222,5223,5269
> > DNAT:info   net dmz:192.168.14.8tcppop3,pop3s,smtp,smtps
> > DNAT:info   net dmz:192.168.14.14tcphttp,https
> >
> > DNS(ACCEPT) loc dmz:192.168.14.12tcp
> > DNS(ACCEPT) loc dmz:192.168.14.12udp
> > FTP(ACCEPT):info    loc dmz:192.168.14.13
> > Squid(ACCEPT):info  loc dmz:192.168.14.18
> > ACCEPT:info loc dmz:192.168.14.15tcp5222,5223,5269
> > ACCEPT:info loc dmz:192.168.14.8tcppop3,pop3s,smtp,smtps
> > ACCEPT:info loc dmz:192.168.14.14tcphttp,https
> >
> > DNS(ACCEPT) dmz net tcp
> > DNS(ACCEPT) dmz loc tcp
> > DNS(ACCEPT) dmz net udp
> > DNS(ACCEPT) dmz loc udp
> >
> > NTP(ACCEPT):info    dmz loc:192.168.41.16
> > ACCEPT:info dmz
> loc:192.168.41.16tcp111,2049,20048,43810,52834
> > ACCEPT:info dmz
> loc:192.168.41.16udp111,2049,20048,47934,54948
> > SMB(ACCEPT):info    dmz loc:192.168.41.16
> >
> >  - As I mentioned early, my network have an authorized IP address
> from
> > where can access to the email service and proxy in the central
> servers,
> > to make this possible I use the snat.
> > 

Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch Offices

[Tom Eastep]

On 09/29/2017 11:34 AM, Jason Timmins wrote:
> Hi Tom,
> 
> Thanks for that.
> 
> I've configured the zones and options files like you suggest but it's not 
> quite working.
> 
> Packets from the branch travel across the tunnel to the firewall and get 
> passed to the Internet but tcpdump suggests that they are not NAT'd. Here's 
> an outbound ping from one machine and a DNS request from another...
> 
> 19:27:15.107897 IP 10.1.4.41 > 8.8.8.8: ICMP echo request, id 3, seq 14396, 
> length 40
> 19:27:18.375539 IP 10.1.4.51.29901 > 8.8.8.8.domain: UDP, length 46
> 
> (10.1.4.0/24 is the branch network.) This is what I have in 
> /etc/shorewall/snat...
> 
> SNAT(1.1.1.1) 10.1.4.0/24 eth0
> SNAT(1.1.1.1) 10.249.1.0/24 eth0
> 
> (Clearly, 1.1.1.1 is a fake public IP address but a real IP address is 
> actually in the file at our end.) 10.249.1.0/24 is the subnet for the LAN in 
> the data centre, masquerading from that subnet works fine.
> 
> Any ideas? Do I need to configure /etc/shorewall/tunnels or anything else?
>

Have you added rules allowing ESP and/or UDP port 4500 from the Internet
to the firewall? You would normally need that or an entry in the tunnels
file which will add those rules.

Please forward the output of 'shorewall dump' collected as described at
http://www.shorewall.org/support.htm#Guidelines. Send it to me privately
as an attachment.

Thanks,
-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch Offices

[Jason Timmins]

Hi Tom,

Thanks for that.

I've configured the zones and options files like you suggest but it's not quite 
working.

Packets from the branch travel across the tunnel to the firewall and get passed 
to the Internet but tcpdump suggests that they are not NAT'd. Here's an 
outbound ping from one machine and a DNS request from another...

19:27:15.107897 IP 10.1.4.41 > 8.8.8.8: ICMP echo request, id 3, seq 14396, 
length 40
19:27:18.375539 IP 10.1.4.51.29901 > 8.8.8.8.domain: UDP, length 46

(10.1.4.0/24 is the branch network.) This is what I have in 
/etc/shorewall/snat...

SNAT(1.1.1.1) 10.1.4.0/24 eth0
SNAT(1.1.1.1) 10.249.1.0/24 eth0

(Clearly, 1.1.1.1 is a fake public IP address but a real IP address is actually 
in the file at our end.) 10.249.1.0/24 is the subnet for the LAN in the data 
centre, masquerading from that subnet works fine.

Any ideas? Do I need to configure /etc/shorewall/tunnels or anything else?

Cheers
Jason.

-Original Message-
From: Tom Eastep [mailto:teas...@shorewall.net] 
Sent: 29 September 2017 18:36
To: shorewall-users@lists.sourceforge.net
Subject: Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch 
Offices

On 09/29/2017 10:14 AM, Jason Timmins wrote:
> Hi Tom,
> 
> Yes, they would. The standard FreeSWAN-based IP service on Linux.
> 

Okay -- this is actually fairly simple.

/etc/shorewall/zones:

#ZONE   TYPEOPTIONS
brvpn   ipsec   mode=tunnel,proto=esp

/etc/shorewall/options

#ZONE   HOSTS   OPTIONS
brvpn   $WAN_IF:0.0.0.0/0   routeback

Note 1: using the routeback option allows the branches to communicate between 
themselves.

Note 2: Here, WAN_IF holds the address of the 'net' interface.

Note 3: if you have other ipsec zones using $WAN_IF, then you will want to list 
the branch subnets rather than simply entering 0.0.0.0/0

Now, just configure the rules and policies and you should be all set.
Remember to configure masquerade/SNAT if the branches use RFC1918 addresses.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Norman Henderson]

Hi Vieri, Here are all of my files (I think) relevant to routing, with any
real addresses changed:

providers:

#NAME   NUMBER  MARKDUPLICATE   INTERFACE   GATEWAY OPTIONS COPY

uni01   1   -   -   usb0192.168.1.1 fallback=50
uni02   2   -   -   usb1192.168.0.1 fallback=50
tvc01   3   -   -   vlan5   111.222.333.444
track,balance=1,persistent
aot01   4   -   -   ppp0-
track,balance=1,persistent
cem50tun5   -   -   tun110.20.0.145
fallback=150,persistent
cem50   6   -   -   vlan4   10.1.15.1   fallback=100
cem09   7   -   -   tun310.20.0.129 track
:qcem0509tvc  8   -   -   tun610.20.0.149 loose
cem0509uni  9   -   -   tun710.20.0.153 loose

mangle:

#ACTION SOURCE  DESTPROTO   DESTSOURCE
 USERTESTLENGTH  TOS CONNBYTES   HELPER  PROBABILITY
DSCP
#   PORT(S) PORT(S)

MARK(25)10.0.69.2   -   tcp smtp
MARK(25)-   10.0.69.2   tcp smtp
MARK(25)fwall   77.88.99.0/29  tcp smtp
MARK(53)-   -   udp 53
MARK(53)fwall   -   udp 53
MARK(16)10.0.69.20  -   udp
sip,iax,1068,1:12000
MARK(16)-   10.0.69.20  udp
sip,iax,1068,1:12000
MARK(16)10.1.0.0/24 10.20.0.129 udp sip,iax,1:12000
MARK(16)10.20.0.129 10.1.0.0/24 udp sip,iax,1:12000
MARK(16)10.1.0.0/24 77.88.99.82 udp sip,iax,1:12000
MARK(16)77.88.99.82 10.1.0.0/24 udp sip,iax,1:12000
MARK(16)fwall   -   udp sip,iax,1:12000
MARK(16)-   fwall   udp sip,iax,1:12000
MARK(80)10.0.69.2   -   tcp http,https
MARK(80)10.0.69.2   -   udp http,https
MARK(80)10.0.69.20  -   tcp http,https
MARK(80)10.0.69.20  -   udp http,https
MARK(200)   10.1.10.248 -   udp openvpn,5000,5001
MARK(200)   fwall   77.88.99.0/29  udp openvpn,5000,5001
MARK(200)   fwall   222.111.444.0/29udp openvpn,5000,5001
TOS(16) -   -   udp iax
TOS(16) -   -   udp -   iax
TOS(16) -   -   udp sip
TOS(16) -   -   udp -   sip
TOS(16) 10.0.69.20  -   udp -   -   -   16
TOS(16) -   10.0.69.20  udp -   -   -   16
DSCP(EF)-   -   udp iax
DSCP(EF)-   -   udp -   iax
DSCP(EF)-   -   udp sip
DSCP(EF)-   -   udp -   sip
DSCP(EF)10.0.69.20  -   udp -   -   -   16
DSCP(EF)-   10.0.69.20  udp -   -   -   16

rtrules:

#SOURCE DESTPROVIDERPRIORITYMARK
-   10.20.200.0/25  cem09   1000
-   10.20.200.0/24  main1001
-   10.20.0.0/23main1002
-   10.0.68.0/22cem50   1012
-   10.1.8.0/21 cem50   1014
-   192.168.0.0/16  cem50   1018
-   192.168.33.0/24 cem50   1019
   -   10.0.68.0/22cem01maf1022
-   10.1.10.0/24cem01maf1024
10.1.10.40   -   tvc01   1201
10.1.10.65   -   tvc01   1202
10.1.13.93   -   tvc01   1203
10.1.15.20   -   tvc01   1204
10.1.15.21   -   tvc01   1205
10.1.10.40   -   aot01   1211
10.1.10.65   -   aot01   1212
10.1.13.93   -   aot01   1213
10.1.15.20   -   aot01   1214
10.1.15.21   -   aot01   1215

10.1.10.248 -   aot01   1263200
10.1.10.248 -   tvc01   1264200
$FW -   uni01   1271200
$FW -   uni02   1272200
$FW -   aot01   1273200
$FW -   tvc01   1274200

#NH#20170228# Following rule is not catching "all" traffic in a TCP
connection. Therefore...
10.0.69.2   -   cem09   128025
#NH#20170228# for now, directing all 10.0.69.2 packets via tun3.
10.0.69.2   -   cem09   1281

10.0.0.0/8  -   cem09   129016


10.1.0.0/24 -   uni01   21005
10.1.0.0/24 -   uni02   21006

10.1.8.0/21 -   aot01   21901
10.1.8.0/21 -   tvc01   21902
10.1.8.0/21 -   uni01   21903

Re: [Shorewall-users] My shorewall config

[Rommel Rodriguez Toirac]

El sept. 28, 2017 11:23 AM, Tom Eastep  escribió:On 09/25/2017 09:09 AM, Rommel Rodriguez Toirac wrote:

>  Hello;

> I have configured a network with shorewall as firewall in a host bastion

> mode and I want to configure a DMZ. 

>  This is a little view of what I have done.

>  

>  I declared three zones in my network; in the 192.168.41.0/24 IP range

> are my internal network (the shorewall firewall use the 172.16.120.1 IP

> to masquerade it) and in the 172.16.120.0/24 my external. The DMZ are in

> 192.168.14.0/24 IP range.

>  

>  The services of email and web browser depend of a first level network

> that are installed in other center (center offices); I mean, there are a

> central email server for all in and out email and a central proxy for

> access to web. For that I have an asigment IP for my email and proxy

> servers that are authorized.

>  

>  My network serve to a thirth level network (municipal offices). email

> (pop3me of the services

> used form then.

> 

>  This is my working around to try the DMZ config.

>  

>  - Declared the zones and the interfaces. Four zones: for the internal

> network (loc), for the external network (net), for the DMZ network (dmz)

> and for the firewall it seft (fw). The interfaces are assignet to the

> corresponding zones using the interfaces identifications.

>  

> fw  firewall

> net ipv4

> loc ipv4

> dmz ipv4

> 

> net enp4s1  tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0

> loc enp5s0  tcpflags,nosmurfs,routefilter,logmartians

> dmz enp7s0  tcpflags,nosmurfs,routefilter,logmartians

> 

>  

>  - Configure the policy. The must simple: allow from the firewall access

> to every network; from the internal network can access to the external

> network and to the DMZ; from the DMZ can access to the local or internal

> network and to the external. From the external network is not allowed

> the access, this will be controlled for the firewall rules. If something

> is needed from the internal network and from the DMZ network to the

> firewall, it will be controlled from the firewall rules

>   In the last places if something is missing it will be rejected.

>  

> fw  net ACCEPT  info

> fw  dmz ACCEPT  info

> fw  loc ACCEPT  info

> loc net ACCEPT  info

> loc dmz ACCEPT  info

> dmz loc ACCEPT  info

> dmz net ACCEPT  info



The above policies make all of the ACCEPT rules in your rules file

unnecessary.



> net all DROP    info

> all all REJECT  info

> 

>  - Rules. Here declared the service needed from my users (in my internal

> network and in the municipal offices) for example the access to the

> instant messages service, to the email services, the access to the DNS

> services and consult to the external DNS from my network

>  

> ?SECTION ALL

> ?SECTION ESTABLISHED

> ?SECTION RELATED

> ?SECTION INVALID

> ?SECTION UNTRACKED

> ?SECTION NEW

> 

> DNS(DNAT):info    net  dmz:192.168.14.12

> FTP(DNAT):info    net  dmz:192.168.14.13

> Squid(DNAT):info    net dmz:192.168.14.18

> DNAT:info   net dmz:192.168.14.15tcp5222,5223,5269

> DNAT:info   net dmz:192.168.14.8tcppop3,pop3s,smtp,smtps

> DNAT:info   net dmz:192.168.14.14tcphttp,https

> 

> DNS(ACCEPT) loc dmz:192.168.14.12tcp

> DNS(ACCEPT) loc dmz:192.168.14.12udp

> FTP(ACCEPT):info    loc dmz:192.168.14.13

> Squid(ACCEPT):info  loc dmz:192.168.14.18

> ACCEPT:info loc dmz:192.168.14.15tcp5222,5223,5269

> ACCEPT:info loc dmz:192.168.14.8tcppop3,pop3s,smtp,smtps

> ACCEPT:info loc dmz:192.168.14.14tcphttp,https

> 

> DNS(ACCEPT) dmz net tcp

> DNS(ACCEPT) dmz loc tcp

> DNS(ACCEPT) dmz net udp

> DNS(ACCEPT) dmz loc udp

> 

> NTP(ACCEPT):info    dmz loc:192.168.41.16

> ACCEPT:info dmz loc:192.168.41.16tcp111,2049,20048,43810,52834

> ACCEPT:info dmz loc:192.168.41.16udp111,2049,20048,47934,54948

> SMB(ACCEPT):info    dmz loc:192.168.41.16

> 

>  - As I mentioned early, my network have an authorized IP address from

> where can access to the email service and proxy in the central servers,

> to make this possible I use the snat. 

>   With snat I masquerade my network too.

>   

> SNAT(172.16.120.8)  192.168.14.8    enp4s1  25,110

> SNAT(172.16.120.2)  192.168.14.18   enp4s1  3128

> SNAT(172.16.120.1)  192.168.41.0/24 enp4s1



According to the dump you sent, the firewall does not have addresses

172.16.120.8 or 172.16.120.2. You must add those addresses to interface

enp4s1 if you want those SNAT rules to work.



>   

>    

>  Using this config the firewall is not working fine. For example, the

> users in the municipal offices can not access to service in my network.



Which zone are the 'municipal offices' in?



> The access to the services in central offices I still can 

Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch Offices

[Tom Eastep]

On 09/29/2017 10:14 AM, Jason Timmins wrote:
> Hi Tom,
> 
> Yes, they would. The standard FreeSWAN-based IP service on Linux.
> 

Okay -- this is actually fairly simple.

/etc/shorewall/zones:

#ZONE   TYPEOPTIONS
brvpn   ipsec   mode=tunnel,proto=esp

/etc/shorewall/options

#ZONE   HOSTS   OPTIONS
brvpn   $WAN_IF:0.0.0.0/0   routeback

Note 1: using the routeback option allows the branches to communicate
between themselves.

Note 2: Here, WAN_IF holds the address of the 'net' interface.

Note 3: if you have other ipsec zones using $WAN_IF, then you will want
to list the branch subnets rather than simply entering 0.0.0.0/0

Now, just configure the rules and policies and you should be all set.
Remember to configure masquerade/SNAT if the branches use RFC1918 addresses.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch Offices

[Jason Timmins]

Hi Tom,

Yes, they would. The standard FreeSWAN-based IP service on Linux.

Cheers
Jason.

-Original Message-
From: Tom Eastep [mailto:teas...@shorewall.net] 
Sent: 29 September 2017 17:16
To: shorewall-users@lists.sourceforge.net
Subject: Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch 
Offices

On 09/28/2017 12:29 PM, Jason Timmins wrote:
> Hi There,
> 
>  
> 
> We've got a few branch offices and we'd like for all their Internet 
> traffic to pass through a Shorewall-based firewall in our data centre.
> Their routers support the creation of IPsec tunnels that can be used 
> as the site's default gateway. How do we configure the central 
> Shorewall server to support that topology? The sites have unique IP 
> subnets and it'd be nice if they could router to each other too. NAT 
> for the entire WAN would, I suppose, happen from the Shorewall server in the 
> DC.
> 
> It looks like it might be possible but I'm struggling with the detail.
> We've used Shorewall quite a bit in the past but this is a much more 
> complicated config.
> 

Would the IPSEC tunnels terminate on the Shorewall system?

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPsec Tunnel as Default Gateway for Branch Offices

[Tom Eastep]

On 09/28/2017 12:29 PM, Jason Timmins wrote:
> Hi There,
> 
>  
> 
> We’ve got a few branch offices and we’d like for all their Internet
> traffic to pass through a Shorewall-based firewall in our data centre.
> Their routers support the creation of IPsec tunnels that can be used as
> the site’s default gateway. How do we configure the central Shorewall
> server to support that topology? The sites have unique IP subnets and
> it’d be nice if they could router to each other too. NAT for the entire
> WAN would, I suppose, happen from the Shorewall server in the DC.
> 
> It looks like it might be possible but I’m struggling with the detail.
> We’ve used Shorewall quite a bit in the past but this is a much more
> complicated config.
> 

Would the IPSEC tunnels terminate on the Shorewall system?

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT+SNAT+FTP Helper Problem

[Tom Eastep]

On 09/29/2017 04:29 AM, Juha Leinonen wrote:
> Hi,
> 
> I'm running Debian 9.1 with
> Linux 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux
> Shorewall version 5.0.15.6
> 
> And I'm unable to get DNAT + SNAT + FTP helper combination working. 
> 
> DNAT + FTP Helper works, but when trying to get source IP address also
> changed traffic never passes to inside interface. 
> Also combination DNAT + SNAT works, but then passive FTP doesn't work as
> conntrack is not following packets. 
> 
> Have anyone by any change happened to stumble into this? This has been
> working flawlessy with old 3.16 kernel and shorewall 4.x.
> 

Just to clarify, I assume that when you add SNAT, you are adding an SNAT
rule that changes the source IP on packets leaving the local interface?

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Tom Eastep]

On 09/29/2017 07:35 AM, Vieri Di Paola via Shorewall-users wrote:
> 
> 
> From: Tom Eastep 
>>
>> Remember that MARK is not a terminating target -- so the *last* MARK
> 
>> rule to match the packet is the one that assigns the mark.
> 
> I was aware of that when I wrote the rules.
> 
> My providers file is:
> 
> ISP1  1   1   -   $IF_ISP1$IF_ISP1_GW 
> track,balance=3,persistent
> ISP2  2   2   -   $IF_ISP2$IF_ISP2_GW 
> track,balance=2,persistent
> ISP3  3   3   -   $IF_ISP3$IF_ISP3_GW 
> track,balance=1,persistent
> ISP4  4   4   -   $IF_ISP4$IF_ISP4_GW 
> track,balance=1,persistent
> 
> 
> ...and the *last* line of my mangle file is:
> 
> MARK(3):P -   193.104.0.136

It is the *next to the last* rule that is causing the problem.

> 
> 
>> Your> statistical MARK rules are overwriting your intended mark values most 
>> of
> 
>> the time. 
> 
> 
> If by "statistical" you mean the marks produced by "balance" in the providers 
> file then am I mistaken to think that the last mangle rule defined overwrites 
> previous marks?
> 
>> You need to populate the TEST column of your route marking> rules to stop 
>> this unintended overwriting of previously assigned marks.
> 
> 
> The TEST column in the mangle file?
> Not quite sure which value to use for a MARK rule on the last line of that 
> file.

Again, it isn't the last rule that is the issue.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Vieri Di Paola via Shorewall-users]

From: Norman Henderson 
>
> MARK(25)10.0.69.2   -   tcp smtp
> MARK(25)-   10.0.69.2   tcp smtp

>

> 10.0.69.2   -   cem09   128025

Could you please share the relevant part of your providers file?

> rtrules 10.0.69.2 - cem09 1281

In my specific example I could very well use policy based routing in rtrules 
without marks.
However, there are other cases where I require to use MARK.

Vieri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Vieri Di Paola via Shorewall-users]

From: Tom Eastep 
>
> Remember that MARK is not a terminating target -- so the *last* MARK

> rule to match the packet is the one that assigns the mark.

I was aware of that when I wrote the rules.

My providers file is:

ISP11   1   -   $IF_ISP1$IF_ISP1_GW 
track,balance=3,persistent
ISP22   2   -   $IF_ISP2$IF_ISP2_GW 
track,balance=2,persistent
ISP33   3   -   $IF_ISP3$IF_ISP3_GW 
track,balance=1,persistent
ISP44   4   -   $IF_ISP4$IF_ISP4_GW 
track,balance=1,persistent


...and the *last* line of my mangle file is:

MARK(3):P   -   193.104.0.136


> Your> statistical MARK rules are overwriting your intended mark values most of

> the time. 


If by "statistical" you mean the marks produced by "balance" in the providers 
file then am I mistaken to think that the last mangle rule defined overwrites 
previous marks?

> You need to populate the TEST column of your route marking> rules to stop 
> this unintended overwriting of previously assigned marks.


The TEST column in the mangle file?
Not quite sure which value to use for a MARK rule on the last line of that file.

Vieri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] DNAT+SNAT+FTP Helper Problem

[Juha Leinonen]

Hi,

I'm running Debian 9.1 with
Linux 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux
Shorewall version 5.0.15.6

And I'm unable to get DNAT + SNAT + FTP helper combination working.

DNAT + FTP Helper works, but when trying to get source IP address also
changed traffic never passes to inside interface.
Also combination DNAT + SNAT works, but then passive FTP doesn't work as
conntrack is not following packets.

Have anyone by any change happened to stumble into this? This has been
working flawlessy with old 3.16 kernel and shorewall 4.x.

Br,
-Juha
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle and network mask

[Tom Eastep]

On 09/27/2017 06:00 AM, Vieri Di Paola via Shorewall-users wrote:
> Hi again,
> 
> It seems that I'm getting mixed results. According to the dump I'm posting in 
> the link below, shouldn't a host accessing 193.104.0.136 on port 443 go out 
> provider marked as 3?
> 
> The dump was taken while trying to open https site at 193.104.0.136 from 
> 10.215.144.48.
> 
> https://drive.google.com/open?id=0B-tpkY1LkI67X0FzWnRMSFRYd1E
> 
> I had mixed results. Sometimes traffic is going out provider 3, and at times 
> it's going out another provider.
> 
> So my previous posts are probably "wrong" in that the netmask has nothing to 
> do with the issue I'm seeing.
> 
> Even if I balance traffic in the providers file, I require traffic to 
> 193.104.0.136 to *always* go out provider 3.
> 

Remember that MARK is not a terminating target -- so the *last* MARK
rule to match the packet is the one that assigns the mark. Your
statistical MARK rules are overwriting your intended mark values most of
the time. You need to populate the TEST column of your route marking
rules to stop this unintended overwriting of previously assigned marks.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users