Am 03.05.2014 00:03, schrieb Tom Eastep: > If that is the case, then there is no point in making tun1 a provider > interface (you never need the default route out of it). Simply configure > OpenVPN to add a route to x.x.x.245/28 out of tun1 when the VPN is > brought up. > >
Hi Tom, it took me a while to get to testing ... I've done it the minimal way - I've added two more lines in rtrules and changed provider order (that has probably not been necessary) and everything works now as I wanted it to. rtrules file: #SOURCE DEST PROVIDER PRIORITY MARK - x.x.x.18/32 tonline 1000 - x.x.x.245/28 ipev 1001 192.168.0.0/24 - tonline 20001 1 192.168.5.0/24 - tonline 20001 1 192.168.0.0/24 - tonline 20002 192.168.5.0/24 - tonline 20002 providers file: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY tonline 1 1 - eth1 192.168.2.1 track ipev 2 2 - tun1 x.x.x.254 track The problem that I had with your proposal was that taking out ipev out of the providers file (and inserting a route after openvpn up), the rules line with port forwarding e.g. DNAT vpn dmz:192.168.0.11:80 tcp 80 - x.x.x.245 did not work anymore (and that was the original feature I really wanted)... but I've decided myself for the variant with two providers and it works fine now. This will also give me the flexibility to use the vpn outbound ip for very special and rare cases. The only odd thing is that during migration phase, I'm having martians in all syslogs caused by the old server of which I'm migrating away, but as long as there's no duplicate ip assignments, I'll be fine. I know why I'm having the martians and it'll be only a matter of days. But otherwise: Wow, I'm glad! yay! :) More fine tuning to follow: usage of vlans on all switches, that will allow me to put both virtual and physical devices into one zone. I need that for only one application, but why do without it if I HAVE the flexibility. :-D Again, thanks for your great support. Greetings Michael ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
