I''ve just discovered that I do not have access to the remote gateways for a set of IPsec tunnels to remote networks. This prevents me from changing the routing table on those gateways. I need "roadwarrior" systems connecting to me local network using OpenVPN (tun) to be able to access those systems. Since the remote gateways don''t know about 10.100.1.0/24, where my OpenVPN IPs are, they are not accessible. The solutions I see: - Run OpenVPN in bridge mode (Is this wise?) - Use netmapping to map the OpenVPN IPs to local IPs? Any other ideas? Thanks, A.
On Thu, 2004-12-30 at 14:32 -0500, Adam Sherman wrote:> I''ve just discovered that I do not have access to the remote gateways > for a set of IPsec tunnels to remote networks. This prevents me from > changing the routing table on those gateways. > > I need "roadwarrior" systems connecting to me local network using > OpenVPN (tun) to be able to access those systems. Since the remote > gateways don''t know about 10.100.1.0/24, where my OpenVPN IPs are, they > are not accessible. > > The solutions I see: > > - Run OpenVPN in bridge mode (Is this wise?) > - Use netmapping to map the OpenVPN IPs to local IPs? > > Any other ideas?SNAT traffic from OpenVPN to the remote IPSEC networks. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>>- Run OpenVPN in bridge mode (Is this wise?) >>- Use netmapping to map the OpenVPN IPs to local IPs?> SNAT traffic from OpenVPN to the remote IPSEC networks.A simple solution, for sure. Thanks Tom. A.
Adam Sherman wrote:>> SNAT traffic from OpenVPN to the remote IPSEC networks. > > A simple solution, for sure. Thanks Tom.Which I can''t figure out... :-( I tried: eth0.2 tun0 10.100.0.1 - - mode=tunnel,tunnel-src=10.100.0.0/24 But I get an "invalid comma separated list" error. eth0.2 is the external interface and also the interface where IPsec tunnels go through. tun0:10.100.1.0/24 is the OpenVPN clients. This is 2.2.0-Beta7. (Which I should upgrade to RC3.) Thanks, A. P.S. Tom, no rush for this, please ignore until after your break!
> Adam Sherman wrote: >>> SNAT traffic from OpenVPN to the remote IPSEC networks. >> >> A simple solution, for sure. Thanks Tom. > > Which I can''t figure out... :-( > > I tried: > > eth0.2 tun0 10.100.0.1 - - mode=tunnel,tunnel-src=10.100.0.0/24 > > But I get an "invalid comma separated list" error. > > eth0.2 is the external interface and also the interface where IPsec > tunnels go through. tun0:10.100.1.0/24 is the OpenVPN clients. > > This is 2.2.0-Beta7. (Which I should upgrade to RC3.) > > Thanks, > > A. > > P.S. Tom, no rush for this, please ignore until after your break!Is eth0.2 an alias because it should read eth0:2 if so Mike
Mike Lander wrote:>> eth0.2 tun0 10.100.0.1 - - mode=tunnel,tunnel-src=10.100.0.0/24> Is eth0.2 an alias because it should read eth0:2 if soNo, it''s a VLAN interface on eth0. Thanks, A.
> Mike Lander wrote: >>> eth0.2 tun0 10.100.0.1 - - mode=tunnel,tunnel-src=10.100.0.0/24 > >> Is eth0.2 an alias because it should read eth0:2 if so > > No, it''s a VLAN interface on eth0. > > Thanks, > > A.I have not plunged into the VLANS yet! Good Luck! Mike
Adam Sherman wrote:> eth0.2 is the external interface and also the interface where IPsec > tunnels go through. tun0:10.100.1.0/24 is the OpenVPN clients.Now running 2.2.0-RC3 with latest "firewall" from CVS. masq has: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0.2 tun0 10.100.0.1 - - mode=tunnel,tunnel-src=10.100.0.0/24 eth0.2 eth0 Pinging 10.100.4.10 from 10.100.1.22 gives me this log entry, same as my previous post about IPsec which Tom explained: Shorewall:all2all:REJECT:IN=tun0 OUT=eth0.2 SRC=10.100.1.22 DST=10.100.4.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=50099 PROTO=ICMP TYPE=8 CODE=0 ID=1379 SEQ=1 I really want this to a) be in a rw2cctc chain, and b) be masqueraded as coming from 10.100.0.1. Other than the above, the configuration is the same as detailed in a previous thread. Thanks, A.
On Thu, 2004-12-30 at 18:54 -0500, Adam Sherman wrote:> Adam Sherman wrote: > > eth0.2 is the external interface and also the interface where IPsec > > tunnels go through. tun0:10.100.1.0/24 is the OpenVPN clients. > > Now running 2.2.0-RC3 with latest "firewall" from CVS. > > masq has: > > #INTERFACE SUBNET ADDRESS PROTO PORT(S) > IPSEC > eth0.2 tun0 10.100.0.1 - - > mode=tunnel,tunnel-src=10.100.0.0/24 > eth0.2 eth0 > > Pinging 10.100.4.10 from 10.100.1.22 gives me this log entry, same as my > previous post about IPsec which Tom explained: > > Shorewall:all2all:REJECT:IN=tun0 OUT=eth0.2 SRC=10.100.1.22 > DST=10.100.4.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=50099 PROTO=ICMP > TYPE=8 CODE=0 ID=1379 SEQ=1 > > I really want this to a) be in a rw2cctc chain, and b) be masqueraded as > coming from 10.100.0.1. Other than the above, the configuration is the > same as detailed in a previous thread.I''ll not help until after the holidays but I have set up a simple configuration where an IPSEC tunnel and an OpenVPN tunnel terminate on the same system and communication between the two VPN worlds works as expected. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>>#INTERFACE SUBNET ADDRESS PROTO PORT(S) >>IPSEC >>eth0.2 tun0 10.100.0.1 - - >>mode=tunnel,tunnel-src=10.100.0.0/24 >>eth0.2 eth0 >> >>Pinging 10.100.4.10 from 10.100.1.22 gives me this log entry, same as my >>previous post about IPsec which Tom explained: >> >>Shorewall:all2all:REJECT:IN=tun0 OUT=eth0.2 SRC=10.100.1.22 >>DST=10.100.4.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=50099 PROTO=ICMP >>TYPE=8 CODE=0 ID=1379 SEQ=1 >> >>I really want this to a) be in a rw2cctc chain, and b) be masqueraded as >>coming from 10.100.0.1. Other than the above, the configuration is the >>same as detailed in a previous thread. > > I''ll not help until after the holidays but I have set up a simple > configuration where an IPSEC tunnel and an OpenVPN tunnel terminate on > the same system and communication between the two VPN worlds works as > expected.I''m sure it is a configuration issue. The telling part is the all@all in the log message, no? Happy New Year! Talk to you later, A.
On Thu, 2004-12-30 at 23:40 -0500, Adam Sherman wrote:> I''m sure it is a configuration issue. > > The telling part is the all@all in the log message, no? >I still believe that it is an SPD issue, And yes, the all2all part is key... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>>The telling part is the all@all in the log message, no? >> > > I still believe that it is an SPD issue, And yes, the all2all part is > key...I''m trying to work around not being able to modify the SPD on the remote systems by using masquerading. Since there is an SPD for 10.100.0.0/24<>10.100.4.0/24, this should be matched once the packet from 10.100.1.0/24 is masqueraded as coming from 10.100.0.1. (Or at least, that''s what *I* want to happen.) Cheers, A.
On Fri, 2004-12-31 at 13:09 -0500, Adam Sherman wrote:> Ok, I think I''m barking up the wrong tree. I now have the following in masq: > > eth0.2 10.100.1.0/24 10.100.0.1 > eth0.2 eth0 > > Pinging 10.100.4.10 from 10.100.1.22 is still blocked in the all2all > chain according to the logs. Now, might this not be a masq problem but > something else? I don''t think the IPsec SPD should have anything to do > with this either, but I''m not very knowledgeable.The problem is that the Netfilter ''filter'' table is traversed *before* SNAT is applied. So while the connection request is going through filtering rules, it is NOT associated with any entry in your SPD so it is not being sent down the rw2cctc chain. I really don''t see any way to work around your problem other than to switch your OpenVPN configuration from tunnel to bridge. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key