On 1/28/19 6:48 AM, Alex wrote:
> Hi,
> 
>>> The problem is that eth1 is associated with 192.168.6.0/24, but a packet
>>> with source IP 192.168.6.1 is being received through br0. On the VPN
>>> client, the loopback interface has been assigned that IP address with is
>>> a duplicate of the IP address of eth1 on the server.
>>
>> I think I've fixed the martian problem, but I still can't reach one
>> side of the VPN from the other and vice-versa.
>>
>> Just to summarize from a few days ago:
>>
>> 192.168.11.0/24 -- <VPN1> -- <VPN2> -- 192.168.1.0/24
>>
>> VPN1 is a dynamic IP (currently 68.192.251.223) with a freedns
>> hostname. VPN2 has a static IP (68.199.193.42). I'd like to be able to
>> reach hosts on either side, as well as the VPN hosts themselves.
>>
>> Currently it doesn't appear that I can reach any host from any other
>> host at all.
> 
> I don't understand why shorewall isn't building the rules necessary
> for packets to pass from one internal network with private IPs to the
> virtual interface with private IPs on the other endpoint:
> 
> On orion (68.199.193.42)
> src 192.168.1.0/24 dst 192.168.11.0/24 uid 0
>         dir out action allow index 8953 priority 1042407 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 2019-01-28 02:53:05 use 2019-01-28 09:46:46
>         tmpl src 68.199.193.42 dst 68.192.251.223
>                 proto esp spi 0x00000000(0) reqid 16389(0x00004005) mode 
> tunnel
>                 level required share any
>                 enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
> 
> $ ping 192.168.11.1
> PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data.
> From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
> 
> On orion (68.199.193.42):
> [393874.843186] FORWARD REJECT IN=eth1 OUT=br0
> MAC=0c:c4:7a:a9:18:df:4c:ed:fb:bb:47:93:08:00 SRC=192.168.1.7
> DST=192.168.11.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=47549 DF
> PROTO=ICMP TYPE=8 CODE=0 ID=26710 SEQ=2258
> 
> 

As explained in Shorewall FAQ 17, when packets are dropped/rejected in
the FORWARD chain, it means that either the SOURCE or the DEST does not
fall into any zone. In this case, the DEST is not in any zone
(192.168.11.0/24) does not appear anywhere in the ruleset).

-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
                      \_______________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to