I''m looking to have my Debian (ver 6.0.6) server act as a router
between network1 (eth1, 10.0.0.0/8) and network2 (eth0,
192.168.0.0/24) while providing Internet access to network1 via
OpenVPN. I would like to do this in a way that prevents network1 from
accessing the Internet in any way except for OpenVPN. It should also
have access to network2 (I have some Samba shares it should have
access to).
So far I can get my Debain server to: 1) correctly connect to the
OpenVPN, 2) Use the VPN for all traffic while the link is up, 3)
(While the VPN links is NOT up) provide basic routing for network1 as
well as access network2 with no issue.
The problem comes with sharing my VPN connection with any host in
network1. Pings to my local network, local DNS, google DNS (8.8.8.8)
and google.com work from the Debian server as well as the host on
network1, as long as the VPN isn''t up. But as soon as it (the VPN
connection) comes up, the hosts on network1 cannot access anything
except the Debian server and network2, pings to the Internet results
in "Request timed out", when pinging Google DNS for testing.
I''ve followed the "two interface example" found in the
documentation,
which works normally without VPN, and have checked "OpenVPN",
"tunnels, "VPN basics" as well. I''ve configured my
testing host on
network1 with a static IP address on that subnet (10.0.0.5).
(the files listed below should show some slight modification, as I
attempted to import some possible solutions from others here on the
mailing list)
**********************************************
INTERFACES
**********************************************
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,tcpflags,nosmurfs,routefilter,logmartians
loc eth1 detect
tcpflags,nosmurfs,routefilter,logmartians
vpn tun0 detect
vpn tap0 detect
**********************************************
ZONES
**********************************************
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4
vpn ipv4
**********************************************
POLICY
**********************************************
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
$FW net ACCEPT
#VPN
loc vpn ACCEPT
#vpn all DROP
$FW vpn ACCEPT
net all DROP info
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
**********************************************
TUNNELS
**********************************************
#TYPE ZONE GATEWAY GATEWAY ZONE
openvpnclient vpn 0.0.0.0/0
**********************************************
MASQ
**********************************************
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK
eth0 10.0.0.0/8
**********************************************
RULES (I haven''t changed anything here from the example, but wanted to
supply it for completeness)
**********************************************
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK
# PORT PORT(S) DEST LIMIT GROUP
#
# Accept DNS connections from the firewall to the network
#
DNS(ACCEPT) $FW net
#
# Accept SSH connections from the local network for administration
#
SSH(ACCEPT) loc $FW
#
# Allow Ping from the local network
#
Ping(ACCEPT) loc $FW
#
# Drop Ping from the "bad" net zone.. and prevent your log from being
flooded..
#
Ping(DROP) net $FW
ACCEPT $FW loc icmp
ACCEPT $FW net icmp
#
**********************************************
RULES (Haven''t change anything here)
**********************************************
#INTERFACE HOST(S) OPTIONS
eth1 -
I''ve verified that my host should be able to route correctly through
OpenVPN:
ip route get 8.8.8.8 from 10.0.0.5 iif eth1
8.8.8.8 from 10.0.0.5 via 93.182.184.129 dev tun0 src 10.0.0.1
cache <src-direct> mtu 1500 advmss 1460 hoplimit 64 iif eth1
(where 10.0.0.5 is my testing host on network1)
ip route ls
93.182.184.130 via 192.168.0.1 dev eth0
93.182.184.128/25 dev tun0 proto kernel scope link src 93.182.184.216
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1
10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1
0.0.0.0/1 via 93.182.184.129 dev tun0
128.0.0.0/1 via 93.182.184.129 dev tun0
default via 192.168.0.1 dev eth0 proto static
I''ve also disable the firewall on the host on network1 to avoid any
interference from that.
If it matters my testing host on network1 is running Windows XP. I''ve
noticed it has some weird behavior when I change my firewall
configuration while it''s running, I reset the machine between testings
to avoid these issues.
The hosts mentioned above are virtual machines on (Vmware) ESXi 5,
with network1 being a virtual network.
>From the "Shorewall Support Guide":
"Try making the connection that is failing.
/sbin/shorewall dump > /tmp/shorewall_dump.txt
Post the /tmp/status.txt file as an attachment compressed with gzip or
bzip2."
Attached find the "shorewall_dump" as above, not sure what the
"status.txt" file mentioned here is, I assume it''s a typo and
you were
looking for the dump file.
Thank you!
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/18/12 7:10 PM, f q wrote:> I''m looking to have my Debian (ver 6.0.6) server act as a router > between network1 (eth1, 10.0.0.0/8) and network2 (eth0, > 192.168.0.0/24) while providing Internet access to network1 via > OpenVPN. I would like to do this in a way that prevents network1 from > accessing the Internet in any way except for OpenVPN. It should also > have access to network2 (I have some Samba shares it should have > access to). >To accomplish this goal, you must use Shorewall''s Multi-ISP capability (http://www.shorewall.net/MultiISP.html). One provider will be associated with eth0 while the other will be associated with tun0. You probably want to make eth0 ''required'' and tun0 ''optional'' in /etc/shorewall/interfaces. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
Apologies for the long reply time, I''ve been quite busy with other projects. I made the changes you requested (see below for specifics). 1) I am able to start the firewall without connection to OpenVPN 2) I am able to connect to OpenVPN without issue with the firewall up 3) I can then restart the firewall with OpenVPN up to enforce traffic shaping with the ''tun0'' adapter 4) I can use the OpenVPN normally during this time 5) I can disconnect the OpenVPN and normal traffic is blocked from traversing my local connection 6) I Cannot reconnect to OpenVPN once this is done, though I have supplied rules in ''tcrules'' to attempt to provide exceptions for OpenVPN traffic. Firewall eth0 ip address: 192.168.0.38, gateway (my home router) 192.168.0.1. I am working from the examples in "MultiISP" (http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT) and "Complex Traffic Shaping" (http://www.shorewall.net/traffic_shaping.htm#tcrules). I am not the most experienced with routing, so I will freely confess that most of the discussion in these articles, I do not completely understand. But the basic idea appears to be: Shape traffic to go over OpenVPN only (mark 2), then provide exceptions for traffic defined in ''tcrules'' such that said traffic is marked for my standard connection (mark 1). Please correct me if I''m wrong. (Including changes to files changed since last post) "providers" #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,balance=1 iPredator 2 2 - tun0 - track,balance=2 "rtrules" #SOURCE DEST PROVIDER PRIORITY - - iPredator 11999 "tcrules" #ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) #allow OpenVPN traffic through 1 $FW 0.0.0.0/0 udp 1194 (I had also tried variations here of: 1 0.0.0.0/0 0.0.0.0/0 udp 1194 As well as: 1 0.0.0.0/0 0.0.0.0/0 udp 1194 1 0.0.0.0/0 0.0.0.0/0 udp - 1194 ) On 11/19/12, Tom Eastep <teastep@shorewall.net> wrote:> On 11/18/12 7:10 PM, f q wrote: >> I''m looking to have my Debian (ver 6.0.6) server act as a router >> between network1 (eth1, 10.0.0.0/8) and network2 (eth0, >> 192.168.0.0/24) while providing Internet access to network1 via >> OpenVPN. I would like to do this in a way that prevents network1 from >> accessing the Internet in any way except for OpenVPN. It should also >> have access to network2 (I have some Samba shares it should have >> access to). >> > > To accomplish this goal, you must use Shorewall''s Multi-ISP capability > (http://www.shorewall.net/MultiISP.html). One provider will be > associated with eth0 while the other will be associated with tun0. You > probably want to make eth0 ''required'' and tun0 ''optional'' in > /etc/shorewall/interfaces. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
On 01/01/2013 01:15 PM, f q wrote:> Apologies for the long reply time, I''ve been quite busy with other projects. > > I made the changes you requested (see below for specifics). > > 1) I am able to start the firewall without connection to OpenVPN > 2) I am able to connect to OpenVPN without issue with the firewall up > 3) I can then restart the firewall with OpenVPN up to enforce traffic > shaping with the ''tun0'' adapter > 4) I can use the OpenVPN normally during this time > 5) I can disconnect the OpenVPN and normal traffic is blocked from > traversing my local connection > 6) I Cannot reconnect to OpenVPN once this is done, though I have > supplied rules in ''tcrules'' to attempt to provide exceptions for > OpenVPN traffic. > > Firewall eth0 ip address: 192.168.0.38, gateway (my home router) 192.168.0.1. > > I am working from the examples in "MultiISP" > (http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT) and "Complex > Traffic Shaping" > (http://www.shorewall.net/traffic_shaping.htm#tcrules). > > I am not the most experienced with routing, so I will freely confess > that most of the discussion in these articles, I do not completely > understand. > > But the basic idea appears to be: Shape traffic to go over OpenVPN > only (mark 2), then provide exceptions for traffic defined in > ''tcrules'' such that said traffic is marked for my standard connection > (mark 1). Please correct me if I''m wrong.Have you configured openvpn to always bind to 192.168.0.38 for its local address? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
First of all: Thank you for your timely reply! I see the list is quite busy and see your name pop-up in most threads; As well as releasing a new version and other personal concerns, you must keep quite busy! In answer to your question, in short no. I''ll post my (redacted) OpenVPN configuration as a more complete answer: client dev tun0 proto udp remote (redacted: OpenVPN provider) 1194 resolv-retry infinite nobind auth-user-pass (redacted: path to auth file) ca [inline] tls-client tls-auth [inline] ns-cert-type server keepalive 10 30 cipher AES-256-CBC tls-cipher TLSv1:!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH persist-key persist-tun comp-lzo tun-mtu 1500 mssfix passtos verb 3 <ca> -----BEGIN CERTIFICATE----- (redacted) -----END CERTIFICATE----- </ca> <tls-auth> -----BEGIN OpenVPN Static key V1----- (redacted) -----END OpenVPN Static key V1----- </tls-auth>>From the manual for my version (2.1.3) of OpenVPN:(http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html) --nobind Do not bind to local address and port. The IP stack will allocate a dynamic port for returning packets. Since the value of the dynamic port could not be known in advance by a peer, this option is only suitable for peers which will be initiating connections by using the --remote option. I attempted an experiment, by adding the option: local 192.168.0.38 And commenting out the "nobind" option in my openVPN configuration, but I observed the same behavior of the "start firewall, connect, restart firewall, disconnect, fail reconnect" as detailed previously. As an aside, I have used this exact client configuration on an older Windows implementation and its (admittedly crappy) firewall. The Firewall configuration follows the same basic pattern as I''m attempting here: Allow port 1194 UDP traffic across any interface, allow traffic to use adapter tun0, block all other traffic, etc; Which does work normally. (Also made a minor change to "tunnels" after reviewing "OPENVPN" again: #TYPE ZONE GATEWAY GATEWAY ZONE openvpnclient:1194 net 0.0.0.0/0 Which did not change the behavior detailed above. ) On 1/2/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/01/2013 01:15 PM, f q wrote: >> Apologies for the long reply time, I''ve been quite busy with other >> projects. >> >> I made the changes you requested (see below for specifics). >> >> 1) I am able to start the firewall without connection to OpenVPN >> 2) I am able to connect to OpenVPN without issue with the firewall up >> 3) I can then restart the firewall with OpenVPN up to enforce traffic >> shaping with the ''tun0'' adapter >> 4) I can use the OpenVPN normally during this time >> 5) I can disconnect the OpenVPN and normal traffic is blocked from >> traversing my local connection >> 6) I Cannot reconnect to OpenVPN once this is done, though I have >> supplied rules in ''tcrules'' to attempt to provide exceptions for >> OpenVPN traffic. >> >> Firewall eth0 ip address: 192.168.0.38, gateway (my home router) >> 192.168.0.1. >> >> I am working from the examples in "MultiISP" >> (http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT) and "Complex >> Traffic Shaping" >> (http://www.shorewall.net/traffic_shaping.htm#tcrules). >> >> I am not the most experienced with routing, so I will freely confess >> that most of the discussion in these articles, I do not completely >> understand. >> >> But the basic idea appears to be: Shape traffic to go over OpenVPN >> only (mark 2), then provide exceptions for traffic defined in >> ''tcrules'' such that said traffic is marked for my standard connection >> (mark 1). Please correct me if I''m wrong. > > Have you configured openvpn to always bind to 192.168.0.38 for its local > address? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
On 01/02/2013 10:48 AM, f q wrote:> First of all: Thank you for your timely reply! I see the list is > quite busy and see your name pop-up in most threads; As well as > releasing a new version and other personal concerns, you must keep > quite busy! >> I attempted an experiment, by adding the option: > > local 192.168.0.38 > > And commenting out the "nobind" option in my openVPN configuration, > but I observed the same behavior of the "start firewall, connect, > restart firewall, disconnect, fail reconnect" as detailed previously. >Did you make an attempt to reconnect before taking the dump that you forwarded? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
On 1/2/13 1:37 PM, Tom Eastep wrote:> On 01/02/2013 10:48 AM, f q wrote: >> First of all: Thank you for your timely reply! I see the list is >> quite busy and see your name pop-up in most threads; As well as >> releasing a new version and other personal concerns, you must keep >> quite busy! >> > >> I attempted an experiment, by adding the option: >> >> local 192.168.0.38 >> >> And commenting out the "nobind" option in my openVPN configuration, >> but I observed the same behavior of the "start firewall, connect, >> restart firewall, disconnect, fail reconnect" as detailed previously. >> > > Did you make an attempt to reconnect before taking the dump that you > forwarded?And are you seeing martian messages in /etc/shorewall/kern.log when you try to reconnect? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
Sorry for the delay, other things, etc. "Did you make an attempt to reconnect before taking the dump that you forwarded?" Right, I attempted to duplicate the issue exactly, before doing a "shorewall dump". "And are you seeing martian messages in /etc/shorewall/kern.log when you try to reconnect?" I don''t have a "/etc/shorewall/kern.log", but I do log to "LOGFILE=/var/log/messages", which appears to contain kernel messages from shorewall: (Where the "Shorewall restarted" is my "shorewall try" command to load my test configuration) Jan 3 11:09:03 iPredator-debian ipredator: Shorewall restarted Jan 3 11:12:29 iPredator-debian kernel: [168457.789332] Shorewall:vpn2fw:REJECT:IN=tun0 OUT= MAC= SRC=2.216.223.111 DST=93.182.186.189 LEN=134 TOS=0x00 PREC=0x00 TTL=113 ID=27441 PROTO=UDP SPT=35408 DPT=25627 LEN=114 MARK=0x2 Jan 3 11:12:31 iPredator-debian kernel: [168459.799275] Shorewall:vpn2fw:REJECT:IN=tun0 OUT= MAC= SRC=2.216.223.111 DST=93.182.186.189 LEN=134 TOS=0x00 PREC=0x00 TTL=113 ID=27451 PROTO=UDP SPT=35408 DPT=25627 LEN=114 MARK=0x2 Jan 3 11:12:35 iPredator-debian kernel: [168463.807191] Shorewall:vpn2fw:REJECT:IN=tun0 OUT= MAC= SRC=2.216.223.111 DST=93.182.186.189 LEN=134 TOS=0x00 PREC=0x00 TTL=113 ID=27460 PROTO=UDP SPT=35408 DPT=25627 LEN=114 MARK=0x2 Jan 3 11:13:14 iPredator-debian kernel: [168501.918589] Shorewall:vpn2fw:REJECT:IN=tun0 OUT= MAC= SRC=50.140.17.176 DST=93.182.186.189 LEN=90 TOS=0x00 PREC=0x00 TTL=109 ID=13353 PROTO=UDP SPT=24265 DPT=63211 LEN=70 MARK=0x2 But while attempting to reconnect, no new information is logged, just the errors on the command line: "Thu Jan 3 11:16:28 2013 write UDPv4 []: Network is unreachable (code=101)" On 1/2/13, Tom Eastep <teastep@shorewall.net> wrote:> On 1/2/13 1:37 PM, Tom Eastep wrote: >> On 01/02/2013 10:48 AM, f q wrote: >>> First of all: Thank you for your timely reply! I see the list is >>> quite busy and see your name pop-up in most threads; As well as >>> releasing a new version and other personal concerns, you must keep >>> quite busy! >>> >> >>> I attempted an experiment, by adding the option: >>> >>> local 192.168.0.38 >>> >>> And commenting out the "nobind" option in my openVPN configuration, >>> but I observed the same behavior of the "start firewall, connect, >>> restart firewall, disconnect, fail reconnect" as detailed previously. >>> >> >> Did you make an attempt to reconnect before taking the dump that you >> forwarded? > > And are you seeing martian messages in /etc/shorewall/kern.log when you > try to reconnect? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
I did find something while inspecting the routing table, I believe: Before connecting to Open VPN: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 default via 192.168.0.1 dev eth0 After connecting, before applying firewall: 93.182.186.129 via 192.168.0.1 dev eth0 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 0.0.0.0/1 via 93.182.186.254 dev tun0 128.0.0.0/1 via 93.182.186.254 dev tun0 default via 192.168.0.1 dev eth0 After connecting, after applying firewall: 93.182.186.129 via 192.168.0.1 dev eth0 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 0.0.0.0/1 via 93.182.186.254 dev tun0 128.0.0.0/1 via 93.182.186.254 dev tun0 default nexthop via 192.168.0.1 dev eth0 weight 1 nexthop dev tun0 weight 2 After disconnecting OpenVPN: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 Disconnecting from openVPN appears to clobber my routing table! I don''t even have a default gateway configured after it get done. What is odd, is that the information logged from OpenVPN doesn''t appear to destroy the routes for anything except things that it has added to the routing table: Log information from OpenVPN when tearing down connection: Thu Jan 3 10:48:16 2013 event_wait : Interrupted system call (code=4) Thu Jan 3 10:48:16 2013 TCP/UDP: Closing socket Thu Jan 3 10:48:16 2013 /sbin/route del -net 93.182.186.129 netmask 255.255.255.255 Thu Jan 3 10:48:16 2013 /sbin/route del -net 0.0.0.0 netmask 128.0.0.0 Thu Jan 3 10:48:16 2013 /sbin/route del -net 128.0.0.0 netmask 128.0.0.0 Thu Jan 3 10:48:16 2013 Closing TUN/TAP interface Thu Jan 3 10:48:16 2013 /sbin/ifconfig tun0 0.0.0.0 Thu Jan 3 10:48:17 2013 SIGINT[hard,] received, process exiting Some possible interaction between it and Shorewall? On 1/2/13, Tom Eastep <teastep@shorewall.net> wrote:> On 1/2/13 1:37 PM, Tom Eastep wrote: >> On 01/02/2013 10:48 AM, f q wrote: >>> First of all: Thank you for your timely reply! I see the list is >>> quite busy and see your name pop-up in most threads; As well as >>> releasing a new version and other personal concerns, you must keep >>> quite busy! >>> >> >>> I attempted an experiment, by adding the option: >>> >>> local 192.168.0.38 >>> >>> And commenting out the "nobind" option in my openVPN configuration, >>> but I observed the same behavior of the "start firewall, connect, >>> restart firewall, disconnect, fail reconnect" as detailed previously. >>> >> >> Did you make an attempt to reconnect before taking the dump that you >> forwarded? > > And are you seeing martian messages in /etc/shorewall/kern.log when you > try to reconnect? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
On 01/03/2013 11:18 AM, f q wrote:> Sorry for the delay, other things, etc. > > "Did you make an attempt to reconnect before taking the dump that you > forwarded?" > > Right, I attempted to duplicate the issue exactly, before doing a > "shorewall dump". > > "And are you seeing martian messages in /etc/shorewall/kern.log when you > try to reconnect?" > > I don''t have a "/etc/shorewall/kern.log", but I do log to > "LOGFILE=/var/log/messages", which appears to contain kernel messages > from shorewall:LOGFILE tells /sbin/shorewall where to look for the log; it has nothing to do with where netfiler logs. I assumed (incorrectly) that you are using Debian since you are using the same rather old version of Shorewall that is in Debian Squeeze.> But while attempting to reconnect, no new information is logged, just > the errors on the command line: >> "Thu Jan 3 11:16:28 2013 write UDPv4 []: Network is unreachable (code=101)"-Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
On 01/03/2013 11:21 AM, f q wrote:> I did find something while inspecting the routing table, I believe: > > Before connecting to Open VPN: > > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 > default via 192.168.0.1 dev eth0 > > After connecting, before applying firewall: > > 93.182.186.129 via 192.168.0.1 dev eth0 > 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 > 0.0.0.0/1 via 93.182.186.254 dev tun0 > 128.0.0.0/1 via 93.182.186.254 dev tun0 > default via 192.168.0.1 dev eth0 > > After connecting, after applying firewall: > > 93.182.186.129 via 192.168.0.1 dev eth0 > 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 > 0.0.0.0/1 via 93.182.186.254 dev tun0 > 128.0.0.0/1 via 93.182.186.254 dev tun0 > default > nexthop via 192.168.0.1 dev eth0 weight 1 > nexthop dev tun0 weight 2 > > After disconnecting OpenVPN: > > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 metric 1 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 > > Disconnecting from openVPN appears to clobber my routing table! I > don''t even have a default gateway configured after it get done.That''s a consequence of your using ''balance'' for both providers. When OpenVPN stops, tun0 disappears which causes the balanced route to be removed. If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t happen. Note that you must also set ''routefilter=0'' on both interfaces in /etc/shorewall/interfaces, if you chose to take that approach. Also, when you are running multi-ISP, you must use ''shorewall show routing'' to see the whole routing picture. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
On 01/03/2013 11:47 AM, Tom Eastep wrote:> On 01/03/2013 11:18 AM, f q wrote: >> Sorry for the delay, other things, etc. >> >> "Did you make an attempt to reconnect before taking the dump that you >> forwarded?" >> >> Right, I attempted to duplicate the issue exactly, before doing a >> "shorewall dump". >> >> "And are you seeing martian messages in /etc/shorewall/kern.log when you >> try to reconnect?" >> >> I don''t have a "/etc/shorewall/kern.log", but I do log to >> "LOGFILE=/var/log/messages", which appears to contain kernel messages >> from shorewall: > > LOGFILE tells /sbin/shorewall where to look for the log; it has nothing > to do with where netfiler logs. > > I assumed (incorrectly) that you are using Debian since you are using > the same rather old version of Shorewall that is in Debian Squeeze.I re-checked and you appear to be running Debian Squeeze; do you have a non-standard rsyslogd configuration? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
"If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t happen. Note that you must also set ''routefilter=0'' on both interfaces in /etc/shorewall/interfaces, if you chose to take that approach." #providers #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,fallback=1 iPredator 2 2 - tun0 - track,balance=2 #interfaces #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required vpn tun0 detect optional,routefilter=0 I completed the above steps, which caused some odd behavior: 1) When already connected to OpenVPN, the VPN functioned as expected 2) When disconnecting from the VPN, traffic was routed through eth0 through my default connection (seemingly ignoring all the work with providers / tcrules / etc) 3) When reconnecting to the OpenVPN my traffic continued through my default connection, ignoring the VPN entirely! 4) Disconnecting from the VPN, applying the firewall and reconnecting now allows no traffic to exit my firewall at all! 5) Disconnecting from the VPN when in state (4), will allow traffic, but then only through my default connection. Reverting to previous, semi-working configuration. On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/03/2013 11:21 AM, f q wrote: >> I did find something while inspecting the routing table, I believe: >> >> Before connecting to Open VPN: >> >> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 >> metric 1 >> 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 >> default via 192.168.0.1 dev eth0 >> >> After connecting, before applying firewall: >> >> 93.182.186.129 via 192.168.0.1 dev eth0 >> 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 >> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 >> metric 1 >> 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 >> 0.0.0.0/1 via 93.182.186.254 dev tun0 >> 128.0.0.0/1 via 93.182.186.254 dev tun0 >> default via 192.168.0.1 dev eth0 >> >> After connecting, after applying firewall: >> >> 93.182.186.129 via 192.168.0.1 dev eth0 >> 93.182.186.128/25 dev tun0 proto kernel scope link src 93.182.186.162 >> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 >> metric 1 >> 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 >> 0.0.0.0/1 via 93.182.186.254 dev tun0 >> 128.0.0.0/1 via 93.182.186.254 dev tun0 >> default >> nexthop via 192.168.0.1 dev eth0 weight 1 >> nexthop dev tun0 weight 2 >> >> After disconnecting OpenVPN: >> >> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.38 >> metric 1 >> 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 metric 1 >> >> Disconnecting from openVPN appears to clobber my routing table! I >> don''t even have a default gateway configured after it get done. > > That''s a consequence of your using ''balance'' for both providers. When > OpenVPN stops, tun0 disappears which causes the balanced route to be > removed. > > If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t > happen. Note that you must also set ''routefilter=0'' on both interfaces > in /etc/shorewall/interfaces, if you chose to take that approach. > > Also, when you are running multi-ISP, you must use ''shorewall show > routing'' to see the whole routing picture. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
"I re-checked and you appear to be running Debian Squeeze; do you have a non-standard rsyslogd configuration?" To my knowledge no. This should be a default installation of Squeeze with installations of Shorewall and OpenVPN respectively. Just want to get a minimum configuration working before doing any customization. On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/03/2013 11:47 AM, Tom Eastep wrote: >> On 01/03/2013 11:18 AM, f q wrote: >>> Sorry for the delay, other things, etc. >>> >>> "Did you make an attempt to reconnect before taking the dump that you >>> forwarded?" >>> >>> Right, I attempted to duplicate the issue exactly, before doing a >>> "shorewall dump". >>> >>> "And are you seeing martian messages in /etc/shorewall/kern.log when you >>> try to reconnect?" >>> >>> I don''t have a "/etc/shorewall/kern.log", but I do log to >>> "LOGFILE=/var/log/messages", which appears to contain kernel messages >>> from shorewall: >> >> LOGFILE tells /sbin/shorewall where to look for the log; it has nothing >> to do with where netfiler logs. >> >> I assumed (incorrectly) that you are using Debian since you are using >> the same rather old version of Shorewall that is in Debian Squeeze. > > I re-checked and you appear to be running Debian Squeeze; do you have a > non-standard rsyslogd configuration? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
On 01/03/2013 12:51 PM, f q wrote:> "If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t > happen. Note that you must also set ''routefilter=0'' on both interfaces > in /etc/shorewall/interfaces, if you chose to take that approach." > > #providers > > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS > loc 1 1 - eth0 192.168.0.1 track,fallback=1 > iPredator 2 2 - tun0 - track,balance=2 > > #interfaces > > #ZONE INTERFACE BROADCAST OPTIONS > net eth0 detect > dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required > vpn tun0 detect optional,routefilter=0 > > I completed the above steps, which caused some odd behavior: > > 1) When already connected to OpenVPN, the VPN functioned as expected > 2) When disconnecting from the VPN, traffic was routed through eth0 > through my default connection (seemingly ignoring all the work with > providers / tcrules / etc) > 3) When reconnecting to the OpenVPN my traffic continued through my > default connection, ignoring the VPN entirely! > 4) Disconnecting from the VPN, applying the firewall and reconnecting > now allows no traffic to exit my firewall at all! > 5) Disconnecting from the VPN when in state (4), will allow traffic, > but then only through my default connection. > > Reverting to previous, semi-working configuration.You''ll never get any of this to work right until you install shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken... -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
On 01/03/2013 01:08 PM, Tom Eastep wrote:>> Reverting to previous, semi-working configuration. > > You''ll never get any of this to work right until you install > shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken...You might get away, however, which simply installing and configuring LSM. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712
I installed and configured shorewall-init (PRODUCTS="shorewall", IFUPDOWN=1, etc), in the "stable" repository (4.4.11.6-1). This had no effect on the process previously described. I assume a more recent version of shorewall / shorewall-init would help going forward. I''ll be pursuing that, on another OS, as soon as I can get it up and running. On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/03/2013 12:51 PM, f q wrote: >> "If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t >> happen. Note that you must also set ''routefilter=0'' on both interfaces >> in /etc/shorewall/interfaces, if you chose to take that approach." >> >> #providers >> >> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >> loc 1 1 - eth0 192.168.0.1 track,fallback=1 >> iPredator 2 2 - tun0 - track,balance=2 >> >> #interfaces >> >> #ZONE INTERFACE BROADCAST OPTIONS >> net eth0 detect >> dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required >> vpn tun0 detect optional,routefilter=0 >> >> I completed the above steps, which caused some odd behavior: >> >> 1) When already connected to OpenVPN, the VPN functioned as expected >> 2) When disconnecting from the VPN, traffic was routed through eth0 >> through my default connection (seemingly ignoring all the work with >> providers / tcrules / etc) >> 3) When reconnecting to the OpenVPN my traffic continued through my >> default connection, ignoring the VPN entirely! >> 4) Disconnecting from the VPN, applying the firewall and reconnecting >> now allows no traffic to exit my firewall at all! >> 5) Disconnecting from the VPN when in state (4), will allow traffic, >> but then only through my default connection. >> >> Reverting to previous, semi-working configuration. > > You''ll never get any of this to work right until you install > shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken... > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
On 01/04/2013 09:23 AM, f q wrote:> I installed and configured shorewall-init (PRODUCTS="shorewall", > IFUPDOWN=1, etc), in the "stable" repository (4.4.11.6-1). This had > no effect on the process previously described. I assume a more recent > version of shorewall / shorewall-init would help going forward. > > I''ll be pursuing that, on another OS, as soon as I can get it up and running. > > On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote: >> On 01/03/2013 12:51 PM, f q wrote: >>> "If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t >>> happen. Note that you must also set ''routefilter=0'' on both interfaces >>> in /etc/shorewall/interfaces, if you chose to take that approach." >>> >>> #providers >>> >>> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >>> loc 1 1 - eth0 192.168.0.1 track,fallback=1 >>> iPredator 2 2 - tun0 - track,balance=2 >>> >>> #interfaces >>> >>> #ZONE INTERFACE BROADCAST OPTIONS >>> net eth0 detect >>> dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required >>> vpn tun0 detect optional,routefilter=0 >>> >>> I completed the above steps, which caused some odd behavior: >>> >>> 1) When already connected to OpenVPN, the VPN functioned as expected >>> 2) When disconnecting from the VPN, traffic was routed through eth0 >>> through my default connection (seemingly ignoring all the work with >>> providers / tcrules / etc) >>> 3) When reconnecting to the OpenVPN my traffic continued through my >>> default connection, ignoring the VPN entirely! >>> 4) Disconnecting from the VPN, applying the firewall and reconnecting >>> now allows no traffic to exit my firewall at all! >>> 5) Disconnecting from the VPN when in state (4), will allow traffic, >>> but then only through my default connection. >>> >>> Reverting to previous, semi-working configuration. >> >> You''ll never get any of this to work right until you install >> shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken...Roberto Sanchez maintains a Squeeze repo that has Shorewall 4.5.5.x (the version going into Wheezy). It is linked from the Shorewall Download page. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
On 01/04/2013 09:46 AM, Tom Eastep wrote:> On 01/04/2013 09:23 AM, f q wrote: >> I installed and configured shorewall-init (PRODUCTS="shorewall", >> IFUPDOWN=1, etc), in the "stable" repository (4.4.11.6-1). This had >> no effect on the process previously described. I assume a more recent >> version of shorewall / shorewall-init would help going forward. >> >> I''ll be pursuing that, on another OS, as soon as I can get it up and running. >> >> On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote: >>> On 01/03/2013 12:51 PM, f q wrote: >>>> "If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t >>>> happen. Note that you must also set ''routefilter=0'' on both interfaces >>>> in /etc/shorewall/interfaces, if you chose to take that approach." >>>> >>>> #providers >>>> >>>> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >>>> loc 1 1 - eth0 192.168.0.1 track,fallback=1 >>>> iPredator 2 2 - tun0 - track,balance=2 >>>> >>>> #interfaces >>>> >>>> #ZONE INTERFACE BROADCAST OPTIONS >>>> net eth0 detect >>>> dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required >>>> vpn tun0 detect optional,routefilter=0 >>>> >>>> I completed the above steps, which caused some odd behavior: >>>> >>>> 1) When already connected to OpenVPN, the VPN functioned as expected >>>> 2) When disconnecting from the VPN, traffic was routed through eth0 >>>> through my default connection (seemingly ignoring all the work with >>>> providers / tcrules / etc) >>>> 3) When reconnecting to the OpenVPN my traffic continued through my >>>> default connection, ignoring the VPN entirely! >>>> 4) Disconnecting from the VPN, applying the firewall and reconnecting >>>> now allows no traffic to exit my firewall at all! >>>> 5) Disconnecting from the VPN when in state (4), will allow traffic, >>>> but then only through my default connection. >>>> >>>> Reverting to previous, semi-working configuration. >>> >>> You''ll never get any of this to work right until you install >>> shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken... > > Roberto Sanchez maintains a Squeeze repo that has Shorewall 4.5.5.x (the > version going into Wheezy). It is linked from the Shorewall Download page. >Also, you are going to have to explicitly reject traffic from your local net out of eth0. When OpenVPN stops, tun0 is deleted; that causes all routes and routing rules for that device to be deleted. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
I did as you suggested and upgraded to the latest version in repository linked from the download page. shorewall, shorewall-core, shorewall-init: 4.5.5.3-1~bpo60+1 After upgrading I modified the the ''rtrules'' file to: #SOURCE DEST PROVIDER PRIORITY lo - iPredator 11999 As there was an error with leaving both "SOURCE" and "DESTINATION" set to "-", despite the example I lifted it from. 1) I am able to apply the firewall configuration before connecting to OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable -- Provider iPredator (2) not Started" 2) I am then able to connect to OpenVPN normally. 3) I can then re-apply the firewall configuration without error / warning. 4) I attempt to ping to verify my connection and all such packets are dropped 5) I then disconnect from OpenVPN and I get the error "connect: Network is unreachable" when attempting to ping / reconnect to OpenVPN 6) I then re-apply my firewall configuration 7) Ping''s function normally and I can reconnect to OpenVPN (which functions normally) So, similar behavior before the upgrade, but I can no longer use the OpenVPN connection when the firewall is "fully applied". Attached please find a new dump, taken directly after step 5, as above. On 1/4/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/04/2013 09:23 AM, f q wrote: >> I installed and configured shorewall-init (PRODUCTS="shorewall", >> IFUPDOWN=1, etc), in the "stable" repository (4.4.11.6-1). This had >> no effect on the process previously described. I assume a more recent >> version of shorewall / shorewall-init would help going forward. >> >> I''ll be pursuing that, on another OS, as soon as I can get it up and >> running. >> >> On 1/3/13, Tom Eastep <teastep@shorewall.net> wrote: >>> On 01/03/2013 12:51 PM, f q wrote: >>>> "If you used ''balance'' for tun0 and ''fallback'' for eth0, that wouldn''t >>>> happen. Note that you must also set ''routefilter=0'' on both interfaces >>>> in /etc/shorewall/interfaces, if you chose to take that approach." >>>> >>>> #providers >>>> >>>> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >>>> loc 1 1 - eth0 192.168.0.1 track,fallback=1 >>>> iPredator 2 2 - tun0 - track,balance=2 >>>> >>>> #interfaces >>>> >>>> #ZONE INTERFACE BROADCAST OPTIONS >>>> net eth0 detect >>>> dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required >>>> vpn tun0 detect optional,routefilter=0 >>>> >>>> I completed the above steps, which caused some odd behavior: >>>> >>>> 1) When already connected to OpenVPN, the VPN functioned as expected >>>> 2) When disconnecting from the VPN, traffic was routed through eth0 >>>> through my default connection (seemingly ignoring all the work with >>>> providers / tcrules / etc) >>>> 3) When reconnecting to the OpenVPN my traffic continued through my >>>> default connection, ignoring the VPN entirely! >>>> 4) Disconnecting from the VPN, applying the firewall and reconnecting >>>> now allows no traffic to exit my firewall at all! >>>> 5) Disconnecting from the VPN when in state (4), will allow traffic, >>>> but then only through my default connection. >>>> >>>> Reverting to previous, semi-working configuration. >>> >>> You''ll never get any of this to work right until you install >>> shorewall-init. But 4.5.11.6 Shorewall-init is pretty broken... > > Roberto Sanchez maintains a Squeeze repo that has Shorewall 4.5.5.x (the > version going into Wheezy). It is linked from the Shorewall Download page. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
On 01/04/2013 01:07 PM, f q wrote:> I did as you suggested and upgraded to the latest version in > repository linked from the download page. > > shorewall, shorewall-core, shorewall-init: 4.5.5.3-1~bpo60+1 > > After upgrading I modified the the ''rtrules'' file to: > > #SOURCE DEST PROVIDER PRIORITY > lo - iPredator 11999 > > As there was an error with leaving both "SOURCE" and "DESTINATION" set > to "-", despite the example I lifted it from. > > 1) I am able to apply the firewall configuration before connecting to > OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable > -- Provider iPredator (2) not Started" > 2) I am then able to connect to OpenVPN normally. > 3) I can then re-apply the firewall configuration without error / warning. > 4) I attempt to ping to verify my connection and all such packets are dropped > 5) I then disconnect from OpenVPN and I get the error "connect: > Network is unreachable" when attempting to ping / reconnect to OpenVPN > 6) I then re-apply my firewall configuration > 7) Ping''s function normally and I can reconnect to OpenVPN (which > functions normally) > > So, similar behavior before the upgrade, but I can no longer use the > OpenVPN connection when the firewall is "fully applied". > > Attached please find a new dump, taken directly after step 5, as above.Let''s solve the problems one at a time. Please forward a dump taken after step 4. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
On 01/05/2013 07:42 AM, Tom Eastep wrote:> On 01/04/2013 01:07 PM, f q wrote: >> I did as you suggested and upgraded to the latest version in >> repository linked from the download page. >> >> shorewall, shorewall-core, shorewall-init: 4.5.5.3-1~bpo60+1 >> >> After upgrading I modified the the ''rtrules'' file to: >> >> #SOURCE DEST PROVIDER PRIORITY >> lo - iPredator 11999 >> >> As there was an error with leaving both "SOURCE" and "DESTINATION" set >> to "-", despite the example I lifted it from. >> >> 1) I am able to apply the firewall configuration before connecting to >> OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable >> -- Provider iPredator (2) not Started" >> 2) I am then able to connect to OpenVPN normally. >> 3) I can then re-apply the firewall configuration without error / warning. >> 4) I attempt to ping to verify my connection and all such packets are dropped >> 5) I then disconnect from OpenVPN and I get the error "connect: >> Network is unreachable" when attempting to ping / reconnect to OpenVPN >> 6) I then re-apply my firewall configuration >> 7) Ping''s function normally and I can reconnect to OpenVPN (which >> functions normally) >> >> So, similar behavior before the upgrade, but I can no longer use the >> OpenVPN connection when the firewall is "fully applied". >> >> Attached please find a new dump, taken directly after step 5, as above. > > Let''s solve the problems one at a time. Please forward a dump taken > after step 4.You have ''fallback'' on the ''loc'' provider? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
As requested, please find attached. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/04/2013 01:07 PM, f q wrote: >> I did as you suggested and upgraded to the latest version in >> repository linked from the download page. >> >> shorewall, shorewall-core, shorewall-init: 4.5.5.3-1~bpo60+1 >> >> After upgrading I modified the the ''rtrules'' file to: >> >> #SOURCE DEST PROVIDER PRIORITY >> lo - iPredator 11999 >> >> As there was an error with leaving both "SOURCE" and "DESTINATION" set >> to "-", despite the example I lifted it from. >> >> 1) I am able to apply the firewall configuration before connecting to >> OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable >> -- Provider iPredator (2) not Started" >> 2) I am then able to connect to OpenVPN normally. >> 3) I can then re-apply the firewall configuration without error / >> warning. >> 4) I attempt to ping to verify my connection and all such packets are >> dropped >> 5) I then disconnect from OpenVPN and I get the error "connect: >> Network is unreachable" when attempting to ping / reconnect to OpenVPN >> 6) I then re-apply my firewall configuration >> 7) Ping''s function normally and I can reconnect to OpenVPN (which >> functions normally) >> >> So, similar behavior before the upgrade, but I can no longer use the >> OpenVPN connection when the firewall is "fully applied". >> >> Attached please find a new dump, taken directly after step 5, as above. > > Let''s solve the problems one at a time. Please forward a dump taken > after step 4. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
Apologies, we''ve done so much tweaking trying to resolve the issue, I haven''t posted a current configuration in a bit. Here''s "providers", I can post the other files as well on request: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,balance=1 iPredator 2 2 - tun0 - track,balance=2 On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 07:42 AM, Tom Eastep wrote: >> On 01/04/2013 01:07 PM, f q wrote: >>> I did as you suggested and upgraded to the latest version in >>> repository linked from the download page. >>> >>> shorewall, shorewall-core, shorewall-init: 4.5.5.3-1~bpo60+1 >>> >>> After upgrading I modified the the ''rtrules'' file to: >>> >>> #SOURCE DEST PROVIDER PRIORITY >>> lo - iPredator 11999 >>> >>> As there was an error with leaving both "SOURCE" and "DESTINATION" set >>> to "-", despite the example I lifted it from. >>> >>> 1) I am able to apply the firewall configuration before connecting to >>> OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable >>> -- Provider iPredator (2) not Started" >>> 2) I am then able to connect to OpenVPN normally. >>> 3) I can then re-apply the firewall configuration without error / >>> warning. >>> 4) I attempt to ping to verify my connection and all such packets are >>> dropped >>> 5) I then disconnect from OpenVPN and I get the error "connect: >>> Network is unreachable" when attempting to ping / reconnect to OpenVPN >>> 6) I then re-apply my firewall configuration >>> 7) Ping''s function normally and I can reconnect to OpenVPN (which >>> functions normally) >>> >>> So, similar behavior before the upgrade, but I can no longer use the >>> OpenVPN connection when the firewall is "fully applied". >>> >>> Attached please find a new dump, taken directly after step 5, as above. >> >> Let''s solve the problems one at a time. Please forward a dump taken >> after step 4. > > You have ''fallback'' on the ''loc'' provider? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
On 01/05/2013 01:43 PM, f q wrote:> Apologies, we''ve done so much tweaking trying to resolve the issue, I > haven''t posted a current configuration in a bit. Here''s "providers", > I can post the other files as well on request: > > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS > loc 1 1 - eth0 192.168.0.1 track,balance=1 > iPredator 2 2 - tun0 - track,balance=2 >But you didn''t make the change that I recommended to put ''balance'' on iPredator and ''fallback'' on ''loc''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
On 01/05/2013 01:36 PM, f q wrote:> As requested, please find attached. >And what exactly did you try with this configuration that didn''t work? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
On 01/05/2013 01:48 PM, Tom Eastep wrote:> On 01/05/2013 01:43 PM, f q wrote: >> Apologies, we''ve done so much tweaking trying to resolve the issue, I >> haven''t posted a current configuration in a bit. Here''s "providers", >> I can post the other files as well on request: >> >> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >> loc 1 1 - eth0 192.168.0.1 track,balance=1 >> iPredator 2 2 - tun0 - track,balance=2 >> > > But you didn''t make the change that I recommended to put ''balance'' on > iPredator and ''fallback'' on ''loc''. >Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how USE_DEFAULT_RT=No can possiblly work here, since you have to be able to route between the interfaces and both are provider interfaces. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
I didn''t think to make the change you had recommended on 01/03 again with the new software, apologies. "interfaces": #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required vpn tun0 detect optional,routefilter=0 "providers": #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,fallback=1 iPredator 2 2 - tun0 - track,balance=2 So tracing back through the steps: 1) I am able to apply the firewall configuration before connecting to OpenVPN, with a new error: " Adding Providers... WARNING: Interface tun0 is not usable -- Provider iPredator (2) not Started WARNING: No Default route added (all ''balance'' providers are down) NOTICE: Default route restored " 2) I am then able to connect to OpenVPN normally. 3) I can then re-apply the firewall configuration without error / warning. 4) I attempt to ping to verify my connection and all such packets are dropped 5) I then disconnect from OpenVPN and I get the error "connect: Network is unreachable" when attempting to ping / reconnect to OpenVPN 6) I then re-apply my firewall configuration 7) Ping''s function normally and I can reconnect to OpenVPN (which functions normally The dump attached is taken after step 4, with the above new configuration applied. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 01:43 PM, f q wrote: >> Apologies, we''ve done so much tweaking trying to resolve the issue, I >> haven''t posted a current configuration in a bit. Here''s "providers", >> I can post the other files as well on request: >> >> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >> loc 1 1 - eth0 192.168.0.1 track,balance=1 >> iPredator 2 2 - tun0 - track,balance=2 >> > > But you didn''t make the change that I recommended to put ''balance'' on > iPredator and ''fallback'' on ''loc''. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
With the configuration as follows (with the upgraded Shorewall from the repository you directed me to), I followed these steps and submitted the dump as requested after step 4: "interfaces": #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,nosmurfs,routefilter,logmartians,required vpn tun0 detect optional "providers": #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,balance=1 iPredator 2 2 - tun0 - track,balance=2 1) I am able to apply the firewall configuration before connecting to OpenVPN, with the normal error: "WARNING: Interface tun0 is not usable -- Provider iPredator (2) not Started" 2) I am then able to connect to OpenVPN normally. 3) I can then re-apply the firewall configuration without error / warning. 4) I attempt to ping to verify my connection and all such packets are dropped 5) I then disconnect from OpenVPN and I get the error "connect: Network is unreachable" when attempting to ping / reconnect to OpenVPN 6) I then re-apply my firewall configuration 7) Ping''s function normally and I can reconnect to OpenVPN (which functions normally) On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 01:36 PM, f q wrote: >> As requested, please find attached. >> > > And what exactly did you try with this configuration that didn''t work? > > -Tom > > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how USE_DEFAULT_RT=No can possiblly work here, since you have to be able to route between the interfaces and both are provider interfaces. 1) I made the changes as you requested, and set "USE_DEFAULT_RT=Yes", in /etc/shorewall/shorewall.conf. 2) I issued a /sbin/shorewall restart to re-read the configuration file (I''m not sure this is entirely required, but I wanted to be sure the new changes were being reflected in the current running configuration) 3) Applied the configuration for the firewall, normal warnings: Adding Providers... WARNING: Interface tun0 is not usable -- Provider iPredator (2) not Started WARNING: No Default route added (all ''balance'' providers are down) NOTICE: Default route restored 4) Connected to OpenVPN 5) Attempted to re-apply the firewall configuration, as before (no errors) 6) Attempted pings to verify connection (they traversed the VPN correctly) 7) Disconnected from the VPN, traffic then traversed my default connection incorrectly. Submitting dump after step 7, as above. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 01:48 PM, Tom Eastep wrote: >> On 01/05/2013 01:43 PM, f q wrote: >>> Apologies, we''ve done so much tweaking trying to resolve the issue, I >>> haven''t posted a current configuration in a bit. Here''s "providers", >>> I can post the other files as well on request: >>> >>> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS >>> loc 1 1 - eth0 192.168.0.1 track,balance=1 >>> iPredator 2 2 - tun0 - track,balance=2 >>> >> >> But you didn''t make the change that I recommended to put ''balance'' on >> iPredator and ''fallback'' on ''loc''. >> > > Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how > USE_DEFAULT_RT=No can possiblly work here, since you have to be able to > route between the interfaces and both are provider interfaces. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
On 01/05/2013 02:40 PM, f q wrote:> Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how > USE_DEFAULT_RT=No can possiblly work here, since you have to be able to > route between the interfaces and both are provider interfaces. > > 1) I made the changes as you requested, and set "USE_DEFAULT_RT=Yes", > in /etc/shorewall/shorewall.conf. > 2) I issued a /sbin/shorewall restart to re-read the configuration > file (I''m not sure this is entirely required, but I wanted to be sure > the new changes were being reflected in the current running > configuration) > 3) Applied the configuration for the firewall, normal warnings: > Adding Providers... > WARNING: Interface tun0 is not usable -- Provider iPredator (2) not Started > WARNING: No Default route added (all ''balance'' providers are down) > NOTICE: Default route restored > 4) Connected to OpenVPN > 5) Attempted to re-apply the firewall configuration, as before (no errors) > 6) Attempted pings to verify connection (they traversed the VPN correctly) > 7) Disconnected from the VPN, traffic then traversed my default > connection incorrectly.Come on -- you have to be specific. Exactly what connection did you attempt that worked when you didn''t believe that it should? Give the source iP address, the destination IP address, protocol and port (if appropriate). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912
Apologies, I test my connections by doing a "ping 8.8.8.8" (Google DNS); So: source IP -> 192.168.0.38 (my VPN would be down at this point, after step 7) dest IP -> 8.8.8.8 protocol -> ICMP port -> NA I attempt to start a ping with the OpenVPN up (step 6), to verify they''re going through the VPN (a sort of rough test that saves me from having to do ''traceroute'' to verify the path explicitly, the ping differences through the VPN and my local connection varry by 100''s of milliseconds), then I attempt to disconnect the VPN and monitor the behavior of the ping. If it times out, then the shorewall setup is working as expected (no traffic traversing my local connection "in the clear"), if not and it reverts to traversing my local connection (checking the ping times as above), then I know it''s not working as I hoped it would. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 02:40 PM, f q wrote: >> Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how >> USE_DEFAULT_RT=No can possiblly work here, since you have to be able to >> route between the interfaces and both are provider interfaces. >> >> 1) I made the changes as you requested, and set "USE_DEFAULT_RT=Yes", >> in /etc/shorewall/shorewall.conf. >> 2) I issued a /sbin/shorewall restart to re-read the configuration >> file (I''m not sure this is entirely required, but I wanted to be sure >> the new changes were being reflected in the current running >> configuration) >> 3) Applied the configuration for the firewall, normal warnings: >> Adding Providers... >> WARNING: Interface tun0 is not usable -- Provider iPredator (2) not >> Started >> WARNING: No Default route added (all ''balance'' providers are down) >> NOTICE: Default route restored >> 4) Connected to OpenVPN >> 5) Attempted to re-apply the firewall configuration, as before (no >> errors) >> 6) Attempted pings to verify connection (they traversed the VPN >> correctly) >> 7) Disconnected from the VPN, traffic then traversed my default >> connection incorrectly. > > Come on -- you have to be specific. Exactly what connection did you > attempt that worked when you didn''t believe that it should? Give the > source iP address, the destination IP address, protocol and port (if > appropriate). > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
Also I''d like to thank you for your help. I didn''t expect you to be here in a weekend! I very much appreciate the help. This has been a pet project of mine for quite a while, I''m looking to move away from my current ad hoc kludge (Windows Firewall, Windows XP, etc) and to a more sane approach that I can use to deploy with multiple machines, if I need to. I thought Shorewall was a good fit. I''ve heard a lot of good things. I appreciate your dedication and patience. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 02:40 PM, f q wrote: >> Also, I think you want USE_DEFAULT_RT=Yes. I don''t see how >> USE_DEFAULT_RT=No can possiblly work here, since you have to be able to >> route between the interfaces and both are provider interfaces. >> >> 1) I made the changes as you requested, and set "USE_DEFAULT_RT=Yes", >> in /etc/shorewall/shorewall.conf. >> 2) I issued a /sbin/shorewall restart to re-read the configuration >> file (I''m not sure this is entirely required, but I wanted to be sure >> the new changes were being reflected in the current running >> configuration) >> 3) Applied the configuration for the firewall, normal warnings: >> Adding Providers... >> WARNING: Interface tun0 is not usable -- Provider iPredator (2) not >> Started >> WARNING: No Default route added (all ''balance'' providers are down) >> NOTICE: Default route restored >> 4) Connected to OpenVPN >> 5) Attempted to re-apply the firewall configuration, as before (no >> errors) >> 6) Attempted pings to verify connection (they traversed the VPN >> correctly) >> 7) Disconnected from the VPN, traffic then traversed my default >> connection incorrectly. > > Come on -- you have to be specific. Exactly what connection did you > attempt that worked when you didn''t believe that it should? Give the > source iP address, the destination IP address, protocol and port (if > appropriate). > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
On 01/05/2013 04:13 PM, f q wrote:> Apologies, I test my connections by doing a "ping 8.8.8.8" (Google DNS); So: > > source IP -> 192.168.0.38 (my VPN would be down at this point, after step 7) > dest IP -> 8.8.8.8 > protocol -> ICMP > port -> NAYou have this rule in your rules file: ACCEPT $FW net icmp What do you expect? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
Excellent! Removing the rule causes the firewall to behave as I except. "What do you expect?" I was using this as an example and the line: http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT "Although ''balance'' is automatically assumed when USE_DEFAULT_RT=Yes, you can easily cause all traffic to use one provider except when you explicitly direct it to use the other provider via shorewall-rtrules (5) or shorewall-tcrules (5)." I see now, that this should include "rules" as well, as we had just found. Previous experimentation with "USE_DEFAULT_RT=Yes" with the outdated version prior to upgrade, did not result in any discernible difference, oddly. I was focused on using the files listed here to create the behavior I was looking for, as this appeared to be your recommendation. On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote:> On 01/05/2013 04:13 PM, f q wrote: >> Apologies, I test my connections by doing a "ping 8.8.8.8" (Google DNS); >> So: >> >> source IP -> 192.168.0.38 (my VPN would be down at this point, after step >> 7) >> dest IP -> 8.8.8.8 >> protocol -> ICMP >> port -> NA > > You have this rule in your rules file: > > ACCEPT $FW net icmp > > What do you expect? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
Let me now post my working solution for others who may want this functionality in future: shorewall version -> 4.5.5.3 installed packages: shorewall, shorewall-core, shorewall-init ''interfaces'' #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,nosmurfs,routefilter=0,logmartians,required vpn tun0 detect optional,routefilter=0 ''policy'' #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net DROP #VPN $FW vpn ACCEPT net all DROP info # THE FOLLOWING POLICY MUST BE LAST all all REJECT info ''providers'' #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS loc 1 1 - eth0 192.168.0.1 track,fallback=1 iPredator 2 2 - tun0 - track,balance=2 ''rtrules'' #SOURCE DEST PROVIDER PRIORITY lo - iPredator 11999 ''rules'' #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATEUSER/ MARK # PORT PORT(S) DEST LIMIT GROUP # # Accept DNS connections from the firewall to the network # DNS(ACCEPT) $FW net #Allow OpenVPN traffic to and from the firewall ACCEPT $FW net udp 1194 ACCEPT net $FW udp 1194 # # Drop Ping from the "bad" net zone.. and prevent your log from being flooded.. # Ping(DROP) net $FW ''tcrules'' #ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) #allow OpenVPN traffic through 1 $FW 0.0.0.0/0 udp 1194 ''tunnels'' #TYPE ZONE GATEWAY GATEWAY ZONE openvpnclient:1194 net 0.0.0.0/0 ''zones'' #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 vpn ipv4 (This assumes an OpenVPN client connection [UDP / using a tun* interface] on the default port 1194, originating from the firewall, where no traffic EXCEPT VPN traffic should flow from the firewall.) (Obvious improvements include: Allowing DNS lookups ONLY through VPN [with the exception of lookups of the VPN provider], Allowing connections from / through the firewall to non-routable networks [e.g. the private network outside the eth0 interface on the firewall], a helper script to modify the shorewall configuration to allow different / random ports for use with OpenVPN [some VPN providers will accept OpenVPN connections on any port to circumvent filter of such traffic from an ISP]). All due thanks to Mr. Tom Eastep, for his wonderful product he''s invested so much time and effort into! On 1/5/13, f q <u.predator.eng@gmail.com> wrote:> Excellent! Removing the rule causes the firewall to behave as I except. > > "What do you expect?" > > I was using this as an example and the line: > > http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT > > "Although ''balance'' is automatically assumed when USE_DEFAULT_RT=Yes, > you can easily cause all traffic to use one provider except when you > explicitly direct it to use the other provider via shorewall-rtrules > (5) or shorewall-tcrules (5)." > > I see now, that this should include "rules" as well, as we had just found. > > Previous experimentation with "USE_DEFAULT_RT=Yes" with the outdated > version prior to upgrade, did not result in any discernible > difference, oddly. I was focused on using the files listed here to > create the behavior I was looking for, as this appeared to be your > recommendation. > > On 1/5/13, Tom Eastep <teastep@shorewall.net> wrote: >> On 01/05/2013 04:13 PM, f q wrote: >>> Apologies, I test my connections by doing a "ping 8.8.8.8" (Google DNS); >>> So: >>> >>> source IP -> 192.168.0.38 (my VPN would be down at this point, after >>> step >>> 7) >>> dest IP -> 8.8.8.8 >>> protocol -> ICMP >>> port -> NA >> >> You have this rule in your rules file: >> >> ACCEPT $FW net icmp >> >> What do you expect? >> >> -Tom >> -- >> Tom Eastep \ When I die, I want to go like my Grandfather who >> Shoreline, \ died peacefully in his sleep. Not screaming like >> Washington, USA \ all of the passengers in his car >> http://shorewall.net \________________________________________________ >> >> >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
On 01/05/2013 06:55 PM, f q wrote:> Excellent! Removing the rule causes the firewall to behave as I except. > > "What do you expect?" > > I was using this as an example and the line: > > http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT > > "Although ''balance'' is automatically assumed when USE_DEFAULT_RT=Yes, > you can easily cause all traffic to use one provider except when you > explicitly direct it to use the other provider via shorewall-rtrules > (5) or shorewall-tcrules (5)." > > I see now, that this should include "rules" as well, as we had just found. > > Previous experimentation with "USE_DEFAULT_RT=Yes" with the outdated > version prior to upgrade, did not result in any discernible > difference, oddly. I was focused on using the files listed here to > create the behavior I was looking for, as this appeared to be your > recommendation.You''re welcome -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012