Hi,
hopefully, I'm allowed to ask for issues concerning tun devices from openvpn combined with SuSEfirewall2.
I'm trying to connect two cups servers via openvpn. For some reasons (old firewalls), I want to keep the tun devices, rather then adding tap devices because of the necessary bridging, which is missing the infrastructure in the firewalls.
If I'm not mistaken, it should be possible to forward UDP broadcasts via tun devices. In fact, I'm able to watch the broadcasts flying by in both directions, if I tcpdump the tun device, but for some reason, they're not appearing on the internal eth port, alas they are not forwarded into the local LAN, although I added tun0 to the internal devices, allowed broadcasts, cross forwarded the nets to each other, and added the usual openvpn tun device quirk to scripts/SuSEfirewall2-custom:
FW_DEV_EXT="eth0" FW_DEV_INT="tun0 eth1"
FW_FORWARD="172.16.23.0/24,172.16.24.0/24 172.16.24.0/24,172.16.23.0/24"
FW_ALLOW_FW_BROADCAST_EXT="no" FW_ALLOW_FW_BROADCAST_INT="yes" FW_ALLOW_FW_BROADCAST_DMZ="no" FW_IGNORE_FW_BROADCAST_EXT="yes" FW_IGNORE_FW_BROADCAST_INT="no" FW_IGNORE_FW_BROADCAST_DMZ="yes"
scripts/SuSEfirewall2-custom: fw_custom_after_antispoofing() { iptables -A INPUT -i tun+ -j ACCEPT iptables -A OUTPUT -o tun+ -j ACCEPT }
Of course, other services do run fine on this vpn including nfs.
What am I missing here?
I experimented with sticking the iptables commands into the other hooks, and also added these: iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -o tun+ -j ACCEPT
but obviously my iptables fu is lacking... On google, I couldn't find any more appealing ideas...
Is somebody listening here, and is able and willing to rescue me from this silly issue, I would be very grateful.
Thanks, Pete
Hans-Peter Jansen wrote:
If I'm not mistaken, it should be possible to forward UDP broadcasts via tun devices.
Broadcasts are not fowarded in general as broadcasts are meant for the local subnet. You need to use bridging if you want multiple networks to appear as one. Alternatively, for relaying cups broadcasts only, cupsd.conf has a BrowseRelay parameter according to the manpage. Maybe that's what you are looking for. Another alternative might be to use DNS service discovery instead of the custom cups broadcasts.
local LAN, although I added tun0 to the internal devices, allowed broadcasts, cross forwarded the nets to each other, and added the usual openvpn tun device quirk to scripts/SuSEfirewall2-custom: [...] FW_DEV_INT="tun0 eth1" [...] scripts/SuSEfirewall2-custom: fw_custom_after_antispoofing() { iptables -A INPUT -i tun+ -j ACCEPT iptables -A OUTPUT -o tun+ -j ACCEPT }
What do you mean by 'usual quirk'? I've never heard about that. You've set tun0 as internal so the above custom rules are not needed.
cu Ludwig
On Wednesday 24 February 2010, 08:54:22 Ludwig Nussel wrote:
Hans-Peter Jansen wrote:
If I'm not mistaken, it should be possible to forward UDP broadcasts via tun devices.
Broadcasts are not fowarded in general as broadcasts are meant for the local subnet. You need to use bridging if you want multiple networks to appear as one. Alternatively, for relaying cups broadcasts only, cupsd.conf has a BrowseRelay parameter according to the manpage. Maybe that's what you are looking for.
Hey, how could I miss that one. Indeed, that solved this perfectly.
Many thanks, Ludwig.
Another alternative might be to use DNS service discovery instead of the custom cups broadcasts.
local LAN, although I added tun0 to the internal devices, allowed broadcasts, cross forwarded the nets to each other, and added the usual openvpn tun device quirk to scripts/SuSEfirewall2-custom: [...] FW_DEV_INT="tun0 eth1" [...] scripts/SuSEfirewall2-custom: fw_custom_after_antispoofing() { iptables -A INPUT -i tun+ -j ACCEPT iptables -A OUTPUT -o tun+ -j ACCEPT }
What do you mean by 'usual quirk'? I've never heard about that. You've set tun0 as internal so the above custom rules are not needed.
http://openvpn.net/index.php/open-source/faq.html#firewall
And by mangling the custom script back and forth, I scrambled it. Here's the correct, but obviously obsolete version:
iptables -A INPUT -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT
Since I use this for more than seven years now, such contructs survive for no good reason sometimes..
Before you start understanding things, everything is Whoodoo anyway.
Thanks for clarification.
Yours, Pete
-
Hans-Peter Jansen -
Ludwig Nussel