Hello, I have the following situation : Server with 2 nics 1 nics connected to the internet, 1 connected to the LAN I have OpenVPN running on the system and the following setting in the tunnels file : ================================== openvpn:2000 net 62.58.0.226 openvpn:2001 net 62.58.0.226 openvpn:2002 net 62.58.0.226 ================================== All tunnels ran for weeks without any problem whatsoever. Now I need to change the IP of the tunnelend of the second tunnel. After changing this ip and restarting shorewall (shorewall restart) the tunnel will not come up and seems to be blocked by the firewall. When I do a ''shorewall clear'' then restart OpenVPN let the tunnel come up once, and then start shorewall again it is possible to open the tunnel while shorewall started. What can I do to find out what is causing this problem? Btw. The system is running Shorewall 2.0.7 Thanks, Peter Lindeman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | Hello, | | I have the following situation : | | Server with 2 nics | | 1 nics connected to the internet, 1 connected to the LAN | | I have OpenVPN running on the system and the following setting in the | tunnels file : | | ==================================| | openvpn:2000 net 62.58.0.226 | openvpn:2001 net 62.58.0.226 | openvpn:2002 net 62.58.0.226 | | ==================================| | All tunnels ran for weeks without any problem whatsoever. | | Now I need to change the IP of the tunnelend of the second tunnel. After | changing this ip and restarting shorewall (shorewall restart) the tunnel | will not come up and seems to be blocked by the firewall. | | When I do a ''shorewall clear'' then restart OpenVPN let the tunnel come | up once, and then start shorewall again it is possible to open the | tunnel while shorewall started. | | What can I do to find out what is causing this problem? Look at your log. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBRaUeO/MAbZfjDLIRAvAZAKDDclAKrila8PURTKvmEkZsph4MJACgjBx6 wNXmmGQ7NNltJpU2LPWQlMo=L5Dx -----END PGP SIGNATURE-----
Tom Eastep wrote:> | When I do a ''shorewall clear'' then restart OpenVPN let the tunnel come > | up once, and then start shorewall again it is possible to open the > | tunnel while shorewall started. > | > | What can I do to find out what is causing this problem? > > Look at your log.What log? In the log from OpenVPN I do not see any incoming connections, therefore it looks like the packet is not going through the firewall but I do not get any messages in the syslog Peter Lindeman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | Tom Eastep wrote: | | |> | When I do a ''shorewall clear'' then restart OpenVPN let the tunnel come |> | up once, and then start shorewall again it is possible to open the |> | tunnel while shorewall started. |> | |> | What can I do to find out what is causing this problem? |> |> Look at your log. | | | What log? Whereever you have configured Netfilter to log Shorewall messages. You are claiming that Shorewall is preventing the connection so unless you have totally messed up setting up Shorewall logging, the rejection should be logged somewhere. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRbYUO/MAbZfjDLIRAg+vAJ4zvjF07L5d6KohsJCzRH14krvulACfZ/Bt EkiRO5u0CG23QNBe1esptOI=umuZ -----END PGP SIGNATURE-----
Usually this is /var/log/messages, at least on debian. -Alex Tom Eastep wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Peter Lindeman wrote: > | Tom Eastep wrote: > | > | > |> | When I do a ''shorewall clear'' then restart OpenVPN let the tunnel > come > |> | up once, and then start shorewall again it is possible to open the > |> | tunnel while shorewall started. > |> | > |> | What can I do to find out what is causing this problem? > |> > |> Look at your log. > | > | > | What log? > > Whereever you have configured Netfilter to log Shorewall messages. You > are claiming that Shorewall is preventing the connection so unless you > have totally messed up setting up Shorewall logging, the rejection > should be logged somewhere. > > - -Tom > - -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFBRbYUO/MAbZfjDLIRAg+vAJ4zvjF07L5d6KohsJCzRH14krvulACfZ/Bt > EkiRO5u0CG23QNBe1esptOI> =umuZ > -----END PGP SIGNATURE----- > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
On Mon, 2004-09-13 at 16:06 +0200, Peter Lindeman wrote:> Tom Eastep wrote: > > > > | When I do a ''shorewall clear'' then restart OpenVPN let the tunnel come > > | up once, and then start shorewall again it is possible to open the > > | tunnel while shorewall started. > > | > > | What can I do to find out what is causing this problem? > > > > Look at your log. > > What log? In the log from OpenVPN I do not see any incoming connections, > therefore it looks like the packet is not going through the firewall but > I do not get any messages in the syslog >You may be experiencing the same thing that I have with OpenVPN. Even though you use the ''port'' statement which is supposed to use the same port value for both ends of the connection, I still wind up using a random high for the initiator. I don''t know if this is due to using TCP instead of UDP (though the docs indicate that should not matter) but I have not been able to change this behavior. I could try the ''local'' option to specify a local IP address to bind to but my system is a Road Warrior with a fluctuating address. Specifying the tunnel in the tunnels file sets up a rule to allow traffic to/from the specified UDP port with the port being the same on both ends. This doesn''t work for me so I don''t use the tunnels file for my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp port and that works fine. -- David Hollis <dhollis@davehollis.com>
David Hollis wrote:>>What log? In the log from OpenVPN I do not see any incoming connections, >>therefore it looks like the packet is not going through the firewall but >>I do not get any messages in the syslog >> > > > You may be experiencing the same thing that I have with OpenVPN. Even > though you use the ''port'' statement which is supposed to use the same > port value for both ends of the connection, I still wind up using a > random high for the initiator. I don''t know if this is due to using TCP > instead of UDP (though the docs indicate that should not matter) but I > have not been able to change this behavior. I could try the ''local'' > option to specify a local IP address to bind to but my system is a Road > Warrior with a fluctuating address.I am using the default UDP so that behaves the same then.> Specifying the tunnel in the tunnels file sets up a rule to allow > traffic to/from the specified UDP port with the port being the same on > both ends. This doesn''t work for me so I don''t use the tunnels file for > my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp port > and that works fine.So I better can make a rule like : ACCEPT net:ip_other_tunnel_end fw udp portnr_of_tunnel and delete the corresponding line in the tunnels file? Correct? -- Groeten, Peter WinErr: 009 Horrible bug encountered - God knows what has happened - - Heb je een Dreambox 7000S ? - Kijk eens op http://www.dreamvcr.com - Kijk ook op http://www.lindeman.org - ICQ 22383596 - Uptime lindeman.org - 59 days, 21 hours and 38 minutes, 1 user logged in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Hollis wrote: | | Specifying the tunnel in the tunnels file sets up a rule to allow | traffic to/from the specified UDP port with the port being the same on | both ends. This doesn''t work for me so I don''t use the tunnels file for | my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp port | and that works fine. | The current Shorewall2/ CVS code has removed this restriction -- the generated rules only enforce the destination port. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRh0TO/MAbZfjDLIRArS/AJ9uOnZE68+aDz2w6YK2izjmRAPs4wCgpfqs vtT7u4CydY7qXIeP6uMq21o=U83S -----END PGP SIGNATURE-----
Tom Eastep wrote:> | Specifying the tunnel in the tunnels file sets up a rule to allow > | traffic to/from the specified UDP port with the port being the same on > | both ends. This doesn''t work for me so I don''t use the tunnels file for > | my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp port > | and that works fine. > | > > The current Shorewall2/ CVS code has removed this restriction -- the > generated rules only enforce the destination port.Aha, tommorrow I am not in the office but will try this on wednesday! Thanks! -- Groeten, Peter WinErr: 01F Reserved for future mistakes of our developers. - - Heb je een Dreambox 7000S ? - Kijk eens op http://www.dreamvcr.com - Kijk ook op http://www.lindeman.org - ICQ 22383596 - Uptime lindeman.org - 60 days, 1 hours and 2 minutes, 1 user logged in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | Tom Eastep wrote: | |> | Specifying the tunnel in the tunnels file sets up a rule to allow |> | traffic to/from the specified UDP port with the port being the same on |> | both ends. This doesn''t work for me so I don''t use the tunnels file |> for |> | my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp |> port |> | and that works fine. |> | |> |> The current Shorewall2/ CVS code has removed this restriction -- the |> generated rules only enforce the destination port. | | | Aha, tommorrow I am not in the office but will try this on wednesday! | Thanks! | Just remember that Shorewall2/ is Shorewall 2.1.8+ - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRistO/MAbZfjDLIRAhedAJ94ppLs1i3TQrVY9VvAMbbouwRJ/wCcDFpu sAH3YiaRMa32wBrB4oLZhEY=5nnA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | Tom Eastep wrote: | |> | Specifying the tunnel in the tunnels file sets up a rule to allow |> | traffic to/from the specified UDP port with the port being the same on |> | both ends. This doesn''t work for me so I don''t use the tunnels file |> for |> | my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp |> port |> | and that works fine. |> | |> |> The current Shorewall2/ CVS code has removed this restriction -- the |> generated rules only enforce the destination port. | | | Aha, tommorrow I am not in the office but will try this on wednesday! | Thanks! Note that you can also define the tunnel as a generic UDP tunnel. In /etc/shorewall/tunnels: generic:udp:2001 net <ip addr> will do exactly what you want. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRyW3O/MAbZfjDLIRAjDhAKC3TWfP93eh6Kz1g/58Wo0BdnNyPACfVDku F4ih+9rDasHHaC06tzSYmNA=bI22 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote: | Peter Lindeman wrote: | | Tom Eastep wrote: | | | |> | Specifying the tunnel in the tunnels file sets up a rule to allow | |> | traffic to/from the specified UDP port with the port being the same on | |> | both ends. This doesn''t work for me so I don''t use the tunnels file | |> for | |> | my connection, rather I permit traffic from ''net'' to ''fw'' on my tcp | |> port | |> | and that works fine. | |> | | |> | |> The current Shorewall2/ CVS code has removed this restriction -- the | |> generated rules only enforce the destination port. | | | | | | Aha, tommorrow I am not in the office but will try this on wednesday! | | Thanks! | | Note that you can also define the tunnel as a generic UDP tunnel. In | /etc/shorewall/tunnels: | | generic:udp:2001 net <ip addr> | | will do exactly what you want. And that will work with any version of Shorewall that supports generic tunnels. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBR1D8O/MAbZfjDLIRAsAuAJ9ZWTCfirbEwoBW6v5VaA7MxCutuACfVDlz JWvPWl1JgZ73FiCBA6/m8cc=l9gy -----END PGP SIGNATURE-----
Tom Eastep wrote:> | Note that you can also define the tunnel as a generic UDP tunnel. In > | /etc/shorewall/tunnels: > | > | generic:udp:2001 net <ip addr> > | > | will do exactly what you want. > > And that will work with any version of Shorewall that supports generic > tunnels.Thanks! Will try that in the morning! -- Groeten, Peter 11th commandment - Covet not thy neighbor''s Pentium Pro. - - Heb je een Dreambox 7000S ? - Kijk eens op http://www.dreamvcr.com - Kijk ook op http://www.lindeman.org - ICQ 22383596 - Uptime lindeman.org - 61 days, 0 hours and 46 minutes, 1 user logged in.
Tom Eastep wrote:> | Aha, tommorrow I am not in the office but will try this on wednesday! > | Thanks! > > Note that you can also define the tunnel as a generic UDP tunnel. In > /etc/shorewall/tunnels: > > generic:udp:2001 net <ip addr> > > will do exactly what you want. >There is something strange here. When I create an entry like above and restart shorewall the other tunnel end can make a connection. I then shutdown the tunnel on the other end. I then remove the entry from /etc/shorewall/tunnels and restart shorewall I the start the tunnel again and surprisingly it connects again. How is this possible? Default traffic from the net zone is being dropped so why can these packages pass by? Thanks, Peter Lindeman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | There is something strange here. | | When I create an entry like above and restart shorewall the other tunnel | end can make a connection. I then shutdown the tunnel on the other end. | | I then remove the entry from /etc/shorewall/tunnels and restart shorewall | | I the start the tunnel again and surprisingly it connects again. How is | this possible? | | Default traffic from the net zone is being dropped so why can these | packages pass by? Two possibilities: a) The remote client always uses the same local port number and it reconnected before the connection tracking entry from the earlier connection had timed out (the default UDP timeout is 30 seconds). b) You have another rule that is allowing the traffic. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSF5xO/MAbZfjDLIRAguFAJ40RiNmvDXMcBCLt7QxrIL2uNqp6wCfb+rJ MjsrmsZPNd+SoUU+N7FQ0v0=iL5J -----END PGP SIGNATURE-----
Tom Eastep wrote:> | I the start the tunnel again and surprisingly it connects again. How is > | this possible? > | > | Default traffic from the net zone is being dropped so why can these > | packages pass by? > > Two possibilities: > > a) The remote client always uses the same local port number and it > reconnected before the connection tracking entry from the earlier > connection had timed out (the default UDP timeout is 30 seconds).It must be this one then but it takes definitly longer then 30 secs, even more then a minute. Can I configure this value somewhere? -- Groeten, Peter Mijn schoonmoeder wandelt alle dagen 5 kilometer. Ik vraag me af waar ze al zit. - - Heb je een Dreambox 7000S ? - Kijk eens op http://www.dreamvcr.com - Kijk ook op http://www.lindeman.org - ICQ 22383596 - Uptime lindeman.org - 61 days, 19 hours and 25 minutes, 1 user logged in.
Tom Eastep wrote:> | It must be this one then but it takes definitly longer then 30 secs, > | even more then a minute. Can I configure this value somewhere? > | > > There are two UDP timeouts: > > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream > > I don''t know how these are used -- check the Netfilter site.Thanks! -- Groeten, Peter Cannot detect carrier. - - Heb je een Dreambox 7000S ? - Kijk eens op http://www.dreamvcr.com - Kijk ook op http://www.lindeman.org - ICQ 22383596 - Uptime lindeman.org - 61 days, 20 hours and 12 minutes, 1 user logged in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Lindeman wrote: | Tom Eastep wrote: | |> | I the start the tunnel again and surprisingly it connects again. How is |> | this possible? |> | |> | Default traffic from the net zone is being dropped so why can these |> | packages pass by? |> |> Two possibilities: |> |> a) The remote client always uses the same local port number and it |> reconnected before the connection tracking entry from the earlier |> connection had timed out (the default UDP timeout is 30 seconds). | | | It must be this one then but it takes definitly longer then 30 secs, | even more then a minute. Can I configure this value somewhere? | There are two UDP timeouts: /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream I don''t know how these are used -- check the Netfilter site. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSH20O/MAbZfjDLIRAsPPAJ0WGp+RXAC3rFzidrhEWUd+KK/ACgCeK/M+ 66BOLpvSc0uMv9RepTo22DE=VZGx -----END PGP SIGNATURE-----