Am 26.04.2014 05:01, schrieb Tom Eastep:
> If you are going to do policy routing with Shorewall, then please do
> it the Shorewall way with /etc/shorewall/providers. Make tun1 an
> optional interface and make it a provider. And I recommend
> USE_DEFAULT_RT=Yes in shorewall.conf. -Tom
ok, I've followed your excellent guide on Multi-ISP setup. Thanks for
that guide, I really appreciate it, as well as your help on the mailing
list.
Thanks to the docs, I got a bit further and I'm trying to automate the
setup.
What I've tested so far:
* ping from the outside on tun1 --> gets forwarded to 192.168.0.11 and
replies back and reply finds the way back to the outside
* same with 192.168.0.11 listening on a tcp port with nc -l xxxx and
outside sending with echo "...." | nc y.y.y.y xxxx and gets reply with
success
--> very great.
It is complex, I know. But let me point out the key steps I've taken
(granted I won't have to repeat my setup from the original post):
* I've removed the two lines as routing is being handled by shorewall
/sbin/ip route add default dev tun1 table tun1.out
/sbin/ip rule add from x.x.x.245 table tun1.out pref 1000
... as well as removed CentOS's default route in
/etc/sysconfig/network-scripts/ifcfg-eth0 :
DEFROUTE=no
(there was none in eth1)
* shorewall.conf:
TRACK_PROVIDERS=Yes
USE_DEFAULT_RT=Yes
... the rest is left at default
* providers:
ipev 1 1 - tun1 x.x.x.254 track,balance=1
tonline 2 2 - eth1 192.168.2.1 track,balance=2
* interfaces:
FORMAT 2
############################
#ZONE INTERFACE OPTIONS
vpn tun1 blacklist,optional
loc eth0 blacklist
net eth1 blacklist
loc eth2 blacklist
* rules:
...
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DNAT vpn loc:192.168.0.11 icmp - - x.x.x.245
DNAT vpn loc:192.168.0.11:6999 tcp 6999 - x.x.x.245
...
(I've changed the zone of the tun1 interface from net to vpn, in
interfaces as well as here).
==> Those rules define the actual port forwards to VMs on the LAN.
* policy:
#SOURCE DEST POLICY LOGLVL
loc net ACCEPT
fw net ACCEPT # (yes, I want that)
vpn net ACCEPT # (seems necessary)
net all DROP info
loc fw ACCEPT
fw loc ACCEPT
fw vpn ACCEPT
loc vpn ACCEPT
vpn all DROP info
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
* masq:
#INTERFACE:DEST SOURCE ADDRESS PROTO PORT(S)
IPSEC MARK
tun1 192.168.0.0/24 192.109.53.245 icmp - - 1
tun1 192.168.0.0/24 192.109.53.245 tcp - - 1
After boot up (i.e. starting up S24openvpn and S28shorewall) it doesn't
work right away.
The first pings get dropped, but with no logging. (DROP counter on tun1
goes up though).
Then comes the fun part:
I restart shorewall again and then I get a martian:
Apr 27 00:53:55 halgw kernel: martian source 192.168.0.11 from
192.168.0.1, on dev eth1
Apr 27 00:53:55 halgw kernel: ll header:
ff:ff:ff:ff:ff:ff:00:xx:xx:xx:xx:xx:08:06
And from that moment on it works!
BTW, as to the martian(s): I've got the interfaces eth0 and eth1 in
different virtual switches of the esxi host, as suggested in the docs
for those cases.
Hard to handle though: when the openvpn connection has a problem for
some reason and has to be restarted, shorewall has to be restarted as
well, because the provider wouldn't be present without an openvpn
connection:
...
Adding Providers...
WARNING: Interface tun1 is not usable -- Provider ipev (1) not Started
...
That chicken/egg problem is hard to automate - it cannot be handled with
the up script of the openvpn connection (where I've put a
'/sbin/shorewall restart'):
root@.......:/etc/openvpn [0] > service openvpn restart
openvpn beenden: [ OK ]
openvpn starten: Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Can't exec "lsmod": No such file or directory at
/usr/share/perl5/vendor_perl/Shorewall/Config.pm line 2645.
ERROR: Can't run lsmod /usr/share/shorewall/modules (line 1)
[FEHLGESCHLAGEN]
Sometimes the openvpn connection just ceases and when I try to restart
openvpn, I can't get through:
Apr 27 01:50:06 ....... openvpn[3744]: write UDPv4: Network is
unreachable (code=101)
Then I have to clear the shorewall, restart openvpn and all is good.
===> My Questions:
How do shorewall and openvpn interact anyways in an ideal multi-isp
world? Do I have to monitor the connection and do a scripted restart of
both, the openvpn connection and shorewall? I've had another
installation (very simple one) where both lived peacefully next to each
other without the need for any restarts.
Is there any other comments on my conf above?
Kind regards
Michael
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
