On 12/11/18 5:22 PM, Alex wrote: > Hi, > > On Tue, Dec 11, 2018 at 7:44 PM Tom Eastep <teas...@shorewall.net> wrote: >> On 12/11/18 3:10 PM, Alex wrote: >>> >>> Here is an example. The 64.1.15.3 IP is in the DMZ behind the remote >>> firewall. This is a mail server trying to communicate with the mail >>> server on the local shorewall firewall. >>> >>> [11440.214121] ext-fw REJECT IN=br0 OUT= >>> MAC=0c:c4:7a:a9:18:de:a4:15:88:a9:30:b7:08:00 SRC=64.1.15.3 >>> DST=68.194.193.42 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=10192 DF >>> PROTO=TCP SPT=52208 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 >>> >>> Here is my local hosts file. >>> vpn >>> br0:192.168.6.0/24,192.168.1.0/24,65.45.72.6,64.1.15.0/27,68.194.193.42,66.103.218.96/28,107.155.66.2 >>> ipsec >>> >>> Here is the output from 'shorewall dump' >>> https://pastebin.com/e8gvjmFr >>> >> The dump shows that there is no IPSec policy that covers 64.1.15.3 -> >> 68.194.193.42. So this traffic is being treated as coming from the vpn >> zone. This is an IPSEC configuration issue, not a Shorewall >> configuration issue.
The above should have read "....is NOT being treated as coming from the vpn
zone".
> Can you explain where you see that the traffic is being treated as
> coming from the VPN zone?
To be treated as coming from the vpn zone, traffic from 64.1.15.3 to
68.194.193.42 must have an IPSec security policy.
From the dump, we see in the Security Policy Database (SPD) that there
are policies from 64.1.15.0/27:
src 64.1.15.0/27 dst 192.168.1.0/24 uid 0
dir fwd action allow index 226 priority 1042404 ptype main share any
flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2018-12-11 17:21:37 use 2018-12-11 18:08:58
tmpl src 65.45.72.6 dst 68.195.192.42
proto esp spi 0x00000000(0) reqid 16397(0x0000400d) mode tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 64.1.15.0/27 dst 192.168.1.0/24 uid 0
dir in action allow index 216 priority 1042404 ptype main share any
flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2018-12-11 17:21:37 use 2018-12-11 18:08:24
tmpl src 65.45.72.6 dst 68.195.192.42
proto esp spi 0x00000000(0) reqid 16397(0x0000400d) mode tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
Both of them cover traffic destined for 192.168.1.0/24; the first is for
forwarded traffic and the second is for input traffic. Since the mail
server is running on the Shorewall system itself, the destination IP
address is 68.194.193.42 which isn't covered by the input policy.
>
> Can I define a VPN policy in shorewall that includes 64.1.15.0/28 and
> 66.103.218.0/27, the two ranges in the DMZ, in the same way I defined
> the 65.45.72.2 endpoint?
If you want the email traffic to be sent through the VPN, then you must
add an ipsec policy for that traffic in your FreeSwan configuration.
>
> Should I remove those ranges from the vpn entry in the shorewall hosts file?
You certainly don't need the IP subnets in that entry. Any traffic
matching an active SPD entry will be treated as coming from or going to
the vpn zone.
-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
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
