Re: [leaf-user] shorewall masquerading packets behind ipsec tunnel
Lynn thanks for the reply I finally got it running, it happened to be an error in the masq file. I masqued to ipsec0 instead of eth0. Tom has done a great job to document shorewall, now either I am not attentive enough to translate all this into a sensible configuration and thus stumble on all those gotchas or it really is still somewhat complex. My set up is probably not what you would call standard but with wireless being more and more frequent configurations like mine may pop up from time to time, so it might be interesting for others to have an example. I might try to document this. Erich At 20:11 16.02.2003 -0600, you wrote: On Sunday 16 February 2003 04:47 pm, Erich Titl wrote: OK, ipsec0 is listening on eth1 (valleygate), correct? After ipsec0 receives and un-encrypts the packets, the true ip information is also unwrapped and interpreted as the actual 192.168.20.0 address that the package was sent from. If this did not hold true, your mountaingate LAN client could never receive a reponse from the valleygate subnet. I imagine that treating the mountaingate subnet as a local network on valleygate via ipsec0 in Shorewall will likely solve your problem. This would also allow the wireless link to remain encrypted. THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] shorewall masquerading packets behind ipsec tunnel
Hi everybody I am still trying to figure out how to (correctly) set up the following. Basic Info: Bering 1_0.stable 2.4.18 with shorewall 1.3.13 network crude ascii art: internet | dynamic IP -- | bering box |this is my standard gateway, operational -- 194.124.158.99 | 194.124.158.98 --- eth0 -- | bering box |valleygate ipsec end point and should NAT from ipsec0 and eth1 -- 192.168.10.1--- eth1 | zone referenced as nocat in shorewall set up | simulates a wireless connection 192.168.10.2 --- eth1 -- | bering box |mountaingate ipsec end point -- 192.168.20.1 --- eth0 | 192.168.20.0/24 upper end subnet Here is some Log Info, please let me know if anything is amiss. ipsec barf on valleygate yields . Feb 14 17:44:39 valleygate Pluto[8400]: valleygate-mountaingate #6: responding to Quick Mode Feb 14 17:44:40 valleygate Pluto[8400]: valleygate-mountaingate #6: IPsec SA established Feb 14 18:33:47 valleygate Pluto[8400]: valleygate-mountaingate #7: responding to Main Mode Feb 14 18:33:47 valleygate Pluto[8400]: valleygate-mountaingate #7: sent MR3, ISAKMP SA established So IMHO I have an established SA whith mountaingate now when I try to connect from the 192.168.20.0/24 subnet to (for example) ssh on 194.124.158.50 the connection is rejected on valleygate by the all2all chain Feb 16 22:27:27 all2all:REJECT:IN=ipsec0 OUT=eth0 SRC=192.168.20.2 DST=194.124.158.50 LEN=48 TOS=0x10 PREC=0x00 TTL=126 ID=70 DF PROTO=TCP SPT=1032 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=2064 This seems to indicate that the tunneled connection from 192.168.20.2 is not masqueraded on valleygate, I must have missed something in the shorewall set up. Here are the shorewall settings for valleygate: interfaces: #ZONEINTERFACE BROADCAST OPTIONS #neteth0detect dhcp,routefilter,norfc1918 net eth0detect routestopped vpn ipsec0 nocat eth1detect routestopped #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE tunnels: # TYPE ZONEGATEWAY GATEWAY ZONE ipsec nocat 192.168.10.2 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE zones: #ZONE DISPLAY COMMENTS net Net Internet nocat NoWire Intermediate Network vpn VPN Remote Network behind VPN tunnel #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE policy: # If you want open access to the internet from your firewall, uncomment the # following line #fw net ACCEPT nocat net ACCEPT net nocat ACCEPT net all DROPinfo all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTE rules: # # Accept DNS connections from the firewall to the network # #ACCEPT fwnet tcp 53 ACCEPT fwnet tcp ACCEPT fwnet udp 53 # # Accept SSH connections from the local network for administration # ACCEPT nocat fwtcp 22 ACCEPT net fwtcp 22 # accept connections to the local network ACCEPT fwnocat tcp ACCEPT fwnocat udp # # Bering specific # ACCEPT nocat fwudp 53 ACCEPT nocat fwtcp 80 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Here is the output from shorewall status after a reset Shorewall-1.3.13 Status at valleygate - Sun Feb 16 22:33:31 CET 2003 Counters reset Sun Feb 16 22:32:41 CET 2003 Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT ah -- lo * 0.0.0.0/00.0.0.0/0 0 0 eth0_inah -- eth0 * 0.0.0.0/00.0.0.0/0 0 0 ipsec0_in ah -- ipsec0 * 0.0.0.0/00.0.0.0/0 3 312 eth1_inah -- eth1 * 0.0.0.0/00.0.0.0/0 0 0 common ah -- * * 0.0.0.0/00.0.0.0/0 0 0 LOGah -- * * 0.0.0.0/00.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:' 0 0 reject ah -- * * 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 eth0_fwd ah -- eth0 * 0.0.0.0/00.0.0.0/0 3 144 ipsec0_fwd ah -- ipsec0 * 0.0.0.0/00.0.0.0/0 0 0 eth1_fwd ah -- eth1 * 0.0.0.0/00.0.0.0/0 0
Re: [leaf-user] shorewall masquerading packets behind ipsec tunnel
On Sunday 16 February 2003 04:47 pm, Erich Titl wrote: 194.124.158.98 --- eth0 -- | bering box |valleygate ipsec end point and should NAT from ipsec0 and eth1 -- 192.168.10.1--- eth1 | zone referenced as nocat in shorewall set up | simulates a wireless connection 192.168.10.2 --- eth1 -- | bering box |mountaingate ipsec end point -- 192.168.20.1 --- eth0 192.168.20.0/24 upper end subnet OK, ipsec0 is listening on eth1 (valleygate), correct? After ipsec0 receives and un-encrypts the packets, the true ip information is also unwrapped and interpreted as the actual 192.168.20.0 address that the package was sent from. If this did not hold true, your mountaingate LAN client could never receive a reponse from the valleygate subnet. I imagine that treating the mountaingate subnet as a local network on valleygate via ipsec0 in Shorewall will likely solve your problem. This would also allow the wireless link to remain encrypted. I hope this helps! -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
