Discussion:
[Shorewall-users] Clients in subnet A cannot access clients in subnet B
Thomas Schneider
2016-06-21 05:08:29 UTC
Permalink
Hello!


I have the following network architecture with

- 2 ISP

- 1 separate router (Fritz!Box)

- Shorewall running on Proxmox VE server


I can only access clients in subnet LAN (10.0.0.0/24) and DMZ
(10.1.0.0/24) from server 192.168.178.10 where Shorewall is running.

From any other server in subnet 192.168.178.0/24 the connection, e.g.
ssh, fails without any error message displayed.


On the router I have configured 2 static routes:

- network 10.0.0.0 / subnet mask 255.255.255.0 / gateway 192.168.178.10

- network 10.1.0.0 / subnet mask 255.255.255.0 / gateway 192.168.178.10


How can I troubleshoot this issue?


THX
Tom Eastep
2016-06-22 14:17:42 UTC
Permalink
Post by Thomas Schneider
Hello!
I have the following network architecture with
- 2 ISP
- 1 separate router (Fritz!Box)
- Shorewall running on Proxmox VE server
I can only access clients in subnet LAN (10.0.0.0/24) and DMZ
(10.1.0.0/24) from server 192.168.178.10 where Shorewall is
running.
From any other server in subnet 192.168.178.0/24 the connection,
e.g. ssh, fails without any error message displayed.
- network 10.0.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
- network 10.1.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
How can I troubleshoot this issue?
When you say 'the router', do you mean the Shorewall system or on the
router that is the default router for 192.168.178.0/24? If the latter,
then you need to be sure that ICMP redirects are enabled on that
router and that the hosts in 192.168.178.0/24 are configured to accept
those redirects.

If you mean that those routes are configured on the Shorewall box,
then you need to add them on the other router because that is where
connections to the 10.x.x.x LANs are being sent.

- -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 \________________________________________________
Thomas Schneider
2016-06-26 12:53:34 UTC
Permalink
Hello!

Indeed I mean the default router for 192.168.178.0/24.
Loading Image...

This router is limited in regards to modifications.
But I have configured a static route on this router.
To enable ICMP redirects, do I need to create related rules in Shorewall
allowing this traffic?

THX
Thomas


P.S.
Where can I find the public key for import that is used to sign this email?
Post by Tom Eastep
Post by Thomas Schneider
Hello!
I have the following network architecture with
- 2 ISP
- 1 separate router (Fritz!Box)
- Shorewall running on Proxmox VE server
I can only access clients in subnet LAN (10.0.0.0/24) and DMZ
(10.1.0.0/24) from server 192.168.178.10 where Shorewall is
running.
From any other server in subnet 192.168.178.0/24 the connection,
e.g. ssh, fails without any error message displayed.
- network 10.0.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
- network 10.1.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
How can I troubleshoot this issue?
When you say 'the router', do you mean the Shorewall system or on the
router that is the default router for 192.168.178.0/24? If the latter,
then you need to be sure that ICMP redirects are enabled on that
router and that the hosts in 192.168.178.0/24 are configured to accept
those redirects.
If you mean that those routes are configured on the Shorewall box,
then you need to add them on the other router because that is where
connections to the 10.x.x.x LANs are being sent.
-Tom
------------------------------------------------------------------------------
Post by Tom Eastep
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
San > Francisco, CA to explore cutting-edge tech and listen to tech
luminaries > present their vision of the future. This family event has
something for > everyone, including kids. Get more information and
register today. > http://sdm.link/attshape >
_______________________________________________ > Shorewall-users
mailing list > Shorewall-***@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Tom Eastep
2016-06-26 14:10:30 UTC
Permalink
Post by Thomas Schneider
Hello!
Indeed I mean the default router for 192.168.178.0/24.
http://up.picr.de/26014890cy.jpg
This router is limited in regards to modifications. But I have
configured a static route on this router. To enable ICMP redirects,
do I need to create related rules in Shorewall allowing this
traffic?
No -- this problem has *nothing* to do with Shorewall.
Post by Thomas Schneider
P.S. Where can I find the public key for import that is used to
sign this email?
The key is available at pool.sks-keyservers.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 \________________________________________________
Tom Eastep
2016-06-26 16:05:14 UTC
Permalink
Post by Tom Eastep
Post by Thomas Schneider
Hello!
Indeed I mean the default router for 192.168.178.0/24.
http://up.picr.de/26014890cy.jpg
This router is limited in regards to modifications. But I have
configured a static route on this router. To enable ICMP
redirects, do I need to create related rules in Shorewall
allowing this traffic?
No -- this problem has *nothing* to do with Shorewall.
If you can get the Fritzbox to start routing the subject packets (or
get it to issue ICMP redirects), there looks like there is a problem
with your Shorewall configuration with regards to traffic from the
'fb' zone to 10.0.0.0/24 network (vmbr0) - I don't see any ACCEPT
rules for that traffic.

- -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 \________________________________________________
Thomas Schneider
2016-06-26 19:32:18 UTC
Permalink
Hi Tom,

I checked configuration and reviewed rules.
For "Ping" and "ICMP" I can see these rules:
## Permit ping access
Ping(ACCEPT) loc,fb $FW
Ping(ACCEPT) $FW loc,fb

## Drop ping access from net
Ping(DROP) net all

## Permit ICMP access
ACCEPT $FW loc,fb icmp
ACCEPT $FW net icmp
ACCEPT loc,fb net icmp


I guess this ruleset is incomplete, right?
And do I need a new rule for Traceroute?


Thanks and regards
Thomas
Post by Tom Eastep
Post by Tom Eastep
Post by Thomas Schneider
Hello!
Indeed I mean the default router for 192.168.178.0/24.
http://up.picr.de/26014890cy.jpg
This router is limited in regards to modifications. But I have
configured a static route on this router. To enable ICMP
redirects, do I need to create related rules in Shorewall
allowing this traffic?
No -- this problem has *nothing* to do with Shorewall.
If you can get the Fritzbox to start routing the subject packets (or
get it to issue ICMP redirects), there looks like there is a problem
with your Shorewall configuration with regards to traffic from the
'fb' zone to 10.0.0.0/24 network (vmbr0) - I don't see any ACCEPT
rules for that traffic.
-Tom
------------------------------------------------------------------------------
Post by Tom Eastep
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
San > Francisco, CA to explore cutting-edge tech and listen to tech
luminaries > present their vision of the future. This family event has
something for > everyone, including kids. Get more information and
register today. > http://sdm.link/attshape >
_______________________________________________ > Shorewall-users
mailing list > Shorewall-***@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Thomas Schneider
2016-06-28 07:03:21 UTC
Permalink
Update:
I have adjusted some rules as follows:
## Permit ping access
Ping(ACCEPT) loc,fb $FW
Ping(ACCEPT) $FW loc,fb
Ping(ACCEPT) fb loc,dmz

## Drop ping access from net
Ping(DROP) net all

## Permit ICMP access
ACCEPT $FW loc,fb icmp
ACCEPT $FW net icmp
ACCEPT loc,fb net icmp
ACCEPT fb loc,dmz icmp

However, I can only ping host pc4-svp.whl.meilocal.net serving
Shorewall: 192.168.178.10 (aka 10.0.0.1 and 10.1.0.1).
http://up.picr.de/26014890cy.jpg

Any ping or traceroute to another server in 10.0.0.0/24 or 10.1.0.0/24
fails after reaching 192.168.178.10.
My conclusion is that the static route configured in router is working,
but then communication is blocked on 192.168.178.10.
***@pc8-nb:~$ sudo traceroute 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
1 pc4-svp.whl.meilocal.net (192.168.178.10) 0.243 ms 0.234 ms 0.231 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
***@pc8-nb:~$ sudo ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
From 192.168.178.1: icmp_seq=124 Redirect Host(New nexthop: 192.168.178.10)
From 192.168.178.1: icmp_seq=424 Redirect Host(New nexthop: 192.168.178.10)


Any advise?
(Shorewall dump attached.)

THX
Thomas

---------------------------------------------------------------------------------------------------------------------

Hi Tom,

I checked configuration and reviewed rules.
For "Ping" and "ICMP" I can see these rules:
## Permit ping access
Ping(ACCEPT) loc,fb $FW
Ping(ACCEPT) $FW loc,fb

## Drop ping access from net
Ping(DROP) net all

## Permit ICMP access
ACCEPT $FW loc,fb icmp
ACCEPT $FW net icmp
ACCEPT loc,fb net icmp


I guess this ruleset is incomplete, right?
And do I need a new rule for Traceroute?


Thanks and regards
Thomas
Post by Tom Eastep
Post by Tom Eastep
Post by Thomas Schneider
Hello!
Indeed I mean the default router for 192.168.178.0/24.
http://up.picr.de/26014890cy.jpg
This router is limited in regards to modifications. But I have
configured a static route on this router. To enable ICMP
redirects, do I need to create related rules in Shorewall
allowing this traffic?
No -- this problem has *nothing* to do with Shorewall.
If you can get the Fritzbox to start routing the subject packets (or
get it to issue ICMP redirects), there looks like there is a problem
with your Shorewall configuration with regards to traffic from the
'fb' zone to 10.0.0.0/24 network (vmbr0) - I don't see any ACCEPT
rules for that traffic.
-Tom
------------------------------------------------------------------------------
Post by Tom Eastep
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
San > Francisco, CA to explore cutting-edge tech and listen to tech
luminaries > present their vision of the future. This family event has
something for > everyone, including kids. Get more information and
register today. > http://sdm.link/attshape >
_______________________________________________ > Shorewall-users
mailing list > Shorewall-***@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Tom Eastep
2016-06-29 14:43:39 UTC
Permalink
Update: I have adjusted some rules as follows: ## Permit ping
access Ping(ACCEPT) loc,fb $FW Ping(ACCEPT) $FW
loc,fb Ping(ACCEPT) fb loc,dmz
## Drop ping access from net Ping(DROP) net all
## Permit ICMP access ACCEPT $FW loc,fb
icmp ACCEPT $FW net icmp
ACCEPT loc,fb net icmp ACCEPT
fb loc,dmz icmp
However, I can only ping host pc4-svp.whl.meilocal.net serving
Shorewall: 192.168.178.10 (aka 10.0.0.1 and 10.1.0.1).
http://up.picr.de/26014890cy.jpg
Any ping or traceroute to another server in 10.0.0.0/24 or
10.1.0.0/24 fails after reaching 192.168.178.10. My conclusion is
that the static route configured in router is working, but then
traceroute 10.0.0.2 traceroute to 10.0.0.2 (10.0.0.2), 30 hops max,
60 byte packets 1 pc4-svp.whl.meilocal.net (192.168.178.10) 0.243
ms 0.234 ms 0.231 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * *
* 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * *
* 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 *
* * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27
10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. From
192.168.178.10) From 192.168.178.1: icmp_seq=424 Redirect Host(New
nexthop: 192.168.178.10)
Any advise?
- From the dump, packets arriving on vmbr2 and to be forwarded go
through the chain UMP_IF_fwd:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
953 76428 UMP_IF_fwd all -- vmbr2 * 0.0.0.0/0
0.0.0.0/0

Since the source IP is in 192.168.178.0/24, they are then passed
through the chain fb_frwd

Chain UMP_IF_fwd (1 references)
pkts bytes target prot opt in out source
destination
953 76428 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
953 76428 smurfs all -- * * 192.168.178.0/24
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
953 76428 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
0 0 tcpflags tcp -- * * 192.168.178.0/24
0.0.0.0/0
0 0 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
953 76428 fb_frwd all -- * * 192.168.178.0/24
0.0.0.0/0
953 76428 net_frwd all -- * * 0.0.0.0/0
0.0.0.0/0


There, *no rule matches the traffic*. So the traffic now goes to net_frw
d:

Chain fb_frwd (1 references)
pkts bytes target prot opt in out source
destination
0 0 fb-net all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 fb-net all -- * vmbr2 0.0.0.0/0
0.0.0.0/0
0 0 all-all all -- * tun+ 0.0.0.0/0
0.0.0.0/0
0 0 ~comb0 all -- * vmbr1 0.0.0.0/0
10.1.0.0/24
0 0 ~comb0 all -- * vmbr1 0.0.0.0/0
224.0.0.0/4

In net_frwd, traffic rouoted out of vmbr0 goes through the net-loc chain
:

Chain net_frwd (2 references)
pkts bytes target prot opt in out source
destination
0 0 ~comb2 all -- * vmbr2 0.0.0.0/0
192.168.178.0/24
0 0 ACCEPT all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * vmbr2 0.0.0.0/0
0.0.0.0/0
118K 153M net-loc all -- * vmbr0 0.0.0.0/0
10.0.0.0/24

There, ping is dropped.

Chain net-loc (2 references)
pkts bytes target prot opt in out source
destination
117K 153M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID
802 67368 DROP icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmptype 8 /* Ping */
52 2404 ACCEPT tcp -- eth0 * 0.0.0.0/0
10.0.0.2 multiport dports 80,443 limit: avg 5/sec burst 10
151 9060 net-all all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]

You appear to have no traceroute rules so traceroute requests get
dropped in net-all, which you can clearly see from the Log section of
the 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 \________________________________________________
Thomas Schneider
2016-06-29 20:24:42 UTC
Permalink
Hello Tom,

I have no doubts in your analysis of the dump.

However, I have no idea about the right conclusions.
You're pointing to some rules stating "no rule matches the traffic".
This confirms my assumption, but I'm not sure what to configure.

These are the current rules for ping/traceroute:
## Drop ping access from net
Ping(DROP) net all

## Permit ping access
Ping(ACCEPT) $FW all
Ping(ACCEPT) loc,fb all

## Permit ICMP access
ACCEPT $FW all icmp
ACCEPT loc,fb all icmp

(There are no more rules related to ping/icmp.)
I would like to ping/traceroute from fb to loc and vice versa, but then
/shorewall check/ reports an error (ERROR: Rules may not override a NONE
policy /usr/share/shorewall/macro.Ping (line 9)).

Now, here are my findings:
Source: $FW (=pc4-svp),
Dest: any client in fb
ping works, traceroute fails
***@pc4-svp:/etc/shorewall# ping 192.168.178.121
PING 192.168.178.121 (192.168.178.121) 56(84) bytes of data.
64 bytes from 192.168.178.121: icmp_seq=1 ttl=128 time=0.239 ms
64 bytes from 192.168.178.121: icmp_seq=2 ttl=128 time=0.114 ms
64 bytes from 192.168.178.121: icmp_seq=3 ttl=128 time=0.169 ms
^C
--- 192.168.1.121 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.114/0.174/0.239/0.051 ms

***@pc4-svp:/etc/shorewall# traceroute 192.168.178.121
traceroute to 192.168.178.121 (192.168.178.121), 30 hops max, 60 byte
packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C

Source: any client in fb
Dest: any client in loc
ping fails, traceroute fails
***@pc8-nb:~$ sudo ping 10.0.0.253
PING 10.0.0.253 (10.0.0.253) 56(84) bytes of data.
From 192.168.178.1: icmp_seq=244 Redirect Host(New nexthop: 192.168.178.10)
From 192.168.178.1: icmp_seq=544 Redirect Host(New nexthop: 192.168.178.10)
From 192.168.178.1: icmp_seq=844 Redirect Host(New nexthop: 192.168.178.10)
^C
--- 10.0.0.253 ping statistics ---
1129 packets transmitted, 0 received, 100% packet loss, time 1128038ms

***@pc8-nb:~$ sudo traceroute 10.0.0.253
traceroute to 10.0.0.253 (10.0.0.253), 30 hops max, 60 byte packets
1 pc4-svp.whl.meilocal.net (192.168.178.10) 0.221 ms 0.206 ms 0.197 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * *^C

This can be seen in /var/log/messages, too.

Dump attached.

Regards,
Thomas
Post by Tom Eastep
Update: I have adjusted some rules as follows: ## Permit ping
access Ping(ACCEPT) loc,fb $FW Ping(ACCEPT) $FW
loc,fb Ping(ACCEPT) fb loc,dmz
## Drop ping access from net Ping(DROP) net all
## Permit ICMP access ACCEPT $FW loc,fb
icmp ACCEPT $FW net icmp
ACCEPT loc,fb net icmp ACCEPT
fb loc,dmz icmp
However, I can only ping host pc4-svp.whl.meilocal.net serving
Shorewall: 192.168.178.10 (aka 10.0.0.1 and 10.1.0.1).
http://up.picr.de/26014890cy.jpg
Any ping or traceroute to another server in 10.0.0.0/24 or
10.1.0.0/24 fails after reaching 192.168.178.10. My conclusion is
that the static route configured in router is working, but then
traceroute 10.0.0.2 traceroute to 10.0.0.2 (10.0.0.2), 30 hops max,
60 byte packets 1 pc4-svp.whl.meilocal.net (192.168.178.10) 0.243
ms 0.234 ms 0.231 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * *
* 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * *
* 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 *
* * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27
10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. From
192.168.178.10) From 192.168.178.1: icmp_seq=424 Redirect Host(New
nexthop: 192.168.178.10)
Any advise?
- From the dump, packets arriving on vmbr2 and to be forwarded go
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
953 76428 UMP_IF_fwd all -- vmbr2 * 0.0.0.0/0
0.0.0.0/0
Since the source IP is in 192.168.178.0/24, they are then passed
through the chain fb_frwd
Chain UMP_IF_fwd (1 references)
pkts bytes target prot opt in out source
destination
953 76428 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
953 76428 smurfs all -- * * 192.168.178.0/24
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
953 76428 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
0 0 tcpflags tcp -- * * 192.168.178.0/24
0.0.0.0/0
0 0 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
953 76428 fb_frwd all -- * * 192.168.178.0/24
0.0.0.0/0
953 76428 net_frwd all -- * * 0.0.0.0/0
0.0.0.0/0
There, *no rule matches the traffic*. So the traffic now goes to net_frw
Chain fb_frwd (1 references)
pkts bytes target prot opt in out source
destination
0 0 fb-net all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 fb-net all -- * vmbr2 0.0.0.0/0
0.0.0.0/0
0 0 all-all all -- * tun+ 0.0.0.0/0
0.0.0.0/0
0 0 ~comb0 all -- * vmbr1 0.0.0.0/0
10.1.0.0/24
0 0 ~comb0 all -- * vmbr1 0.0.0.0/0
224.0.0.0/4
In net_frwd, traffic rouoted out of vmbr0 goes through the net-loc chain
Chain net_frwd (2 references)
pkts bytes target prot opt in out source
destination
0 0 ~comb2 all -- * vmbr2 0.0.0.0/0
192.168.178.0/24
0 0 ACCEPT all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * vmbr2 0.0.0.0/0
0.0.0.0/0
118K 153M net-loc all -- * vmbr0 0.0.0.0/0
10.0.0.0/24
There, ping is dropped.
Chain net-loc (2 references)
pkts bytes target prot opt in out source
destination
117K 153M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID
802 67368 DROP icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmptype 8 /* Ping */
52 2404 ACCEPT tcp -- eth0 * 0.0.0.0/0
10.0.0.2 multiport dports 80,443 limit: avg 5/sec burst 10
151 9060 net-all all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
You appear to have no traceroute rules so traceroute requests get
dropped in net-all, which you can clearly see from the Log section of
the dump.
-Tom
------------------------------------------------------------------------------
Post by Tom Eastep
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
San > Francisco, CA to explore cutting-edge tech and listen to tech
luminaries > present their vision of the future. This family event has
something for > everyone, including kids. Get more information and
register today. > http://sdm.link/attshape >
_______________________________________________ > Shorewall-users
mailing list > Shorewall-***@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Tom Eastep
2016-06-29 20:50:06 UTC
Permalink
Post by Thomas Schneider
Hello Tom,
I have no doubts in your analysis of the dump.
However, I have no idea about the right conclusions. You're
pointing to some rules stating "no rule matches the traffic". This
confirms my assumption, but I'm not sure what to configure.
These are the current rules for ping/traceroute: ## Drop ping
access from net Ping(DROP) net all
## Permit ping access Ping(ACCEPT) $FW all
Ping(ACCEPT) loc,fb all
## Permit ICMP access ACCEPT $FW all
icmp ACCEPT loc,fb all icmp
(There are no more rules related to ping/icmp.) I would like to
ping/traceroute from fb to loc and vice versa, but then /shorewall
check/ reports an error (ERROR: Rules may not override a NONE
policy /usr/share/shorewall/macro.Ping (line 9)).
Now, here are my findings: Source: $FW (=pc4-svp), Dest: any client
ping 192.168.178.121 PING 192.168.178.121 (192.168.178.121) 56(84)
bytes of data. 64 bytes from 192.168.178.121: icmp_seq=1 ttl=128
time=0.239 ms 64 bytes from 192.168.178.121: icmp_seq=2 ttl=128
time=0.114 ms 64 bytes from 192.168.178.121: icmp_seq=3 ttl=128
time=0.169 ms ^C --- 192.168.1.121 ping statistics --- 3 packets
transmitted, 3 received, 0% packet loss, time 1998ms rtt
min/avg/max/mdev = 0.114/0.174/0.239/0.051 ms
to 192.168.178.121 (192.168.178.121), 30 hops max, 60 byte packets
1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 *^C
Source: any client in fb Dest: any client in loc ping fails,
icmp_seq=244 Redirect Host(New nexthop: 192.168.178.10) From
192.168.178.10) From 192.168.178.1: icmp_seq=844 Redirect Host(New
nexthop: 192.168.178.10) ^C --- 10.0.0.253 ping statistics --- 1129
packets transmitted, 0 received, 100% packet loss, time 1128038ms
10.0.0.253 (10.0.0.253), 30 hops max, 60 byte packets 1
pc4-svp.whl.meilocal.net (192.168.178.10) 0.221 ms 0.206 ms
0.197 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 *
* * 9 * * * 10 * * * 11 * * * 12 * *^C
Please forward (privately) a tarball of your /etc/shorewall directory.

Thanks,
- -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 \________________________________________________
Tom Eastep
2016-06-30 14:28:34 UTC
Permalink
sure... tarball attached.
Several things:

1) NONE policies are only to be used when *no* traffic is ever
expected between the SOURCE and DEST zones. That is why Rules are
not allowed between zones with a policy of NONE. Since you do want
to allow some traffic, REJECT would be a better policy. You then
need to add rules for the traffic you wish to accept.

2) For Linux traceroute, you need to use the Trcrt macro.

3) Your ACCEPT rules for all icmp types are not needed.

4) The configuration in the dump doesn't match the configuration that
you sent in the tarball with respect to ping. Be sure that
'shorewall reload -c' compiles and loads your configuration
successfully.

- -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 \________________________________________________
Thomas Schneider
2016-06-26 12:44:00 UTC
Permalink
Hello!

Indeed I mean the default router for 192.168.178.0/24.
Please allow me to add this PDF that documents the architecture.

This router is limited in regards to modifications.
But I have configured a static route on this router.
To enable ICMP redirects, do I need to create related rules in Shorewall
allowing this traffic?

THX
Thomas


P.S.
Where can I find the public key for import that is used to sign this email?
Post by Tom Eastep
Post by Thomas Schneider
Hello!
I have the following network architecture with
- 2 ISP
- 1 separate router (Fritz!Box)
- Shorewall running on Proxmox VE server
I can only access clients in subnet LAN (10.0.0.0/24) and DMZ
(10.1.0.0/24) from server 192.168.178.10 where Shorewall is
running.
From any other server in subnet 192.168.178.0/24 the connection,
e.g. ssh, fails without any error message displayed.
- network 10.0.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
- network 10.1.0.0 / subnet mask 255.255.255.0 / gateway
192.168.178.10
How can I troubleshoot this issue?
When you say 'the router', do you mean the Shorewall system or on the
router that is the default router for 192.168.178.0/24? If the latter,
then you need to be sure that ICMP redirects are enabled on that
router and that the hosts in 192.168.178.0/24 are configured to accept
those redirects.
If you mean that those routes are configured on the Shorewall box,
then you need to add them on the other router because that is where
connections to the 10.x.x.x LANs are being sent.
-Tom
------------------------------------------------------------------------------
Post by Tom Eastep
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
San > Francisco, CA to explore cutting-edge tech and listen to tech
luminaries > present their vision of the future. This family event has
something for > everyone, including kids. Get more information and
register today. > http://sdm.link/attshape >
_______________________________________________ > Shorewall-users
mailing list > Shorewall-***@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Loading...