Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
I'm having a hard time understanding the shorewall config at the moment so I'm going to go back to the iptables config you posted which I assume shorewall generated and will edit this post on any findings.
Okay, I think I understand the shorewall situation a bit more. It's hard to say perfectly without looking at a few shorewall config files. From what I can tell you need to explicitly tell shorewall to trust your virtual interface (ham0). So reading up a bit on their documentation the first thing you should do is create a zone for your hamachi connection, let call it ham, in your
Then add your interface to
ham ham0 -
and lastly allow traffic on the newly created zone
# /etc/shorewall/policy OR /etc/shorewall/rules
ham <ZONE FOR YOUR LOCAL ETH> ACCEPT
<ZONE FOR YOUR LOCAL ETH> ham ACCEPT
Then restart shorewall.
The above example, will allow all traffic in and out on the VPN network so you may want to adjust the policy accordingly. I've never used shorewall but reading the docs this should work???
Remeber to back up all config files before modifying them so you have something to fall back to
Ps. Like I've said I've never used shorewall before and I'm basing my suggestion from what I've read online so correct me if I am completely wrong regarding shorewall configs!
Last edited by kenneth_phough; 01-11-2013 at 08:44 AM.
I have found that if I start hamachi, login, and set mode to ipv4, AND then restart shorewall, vncviewer connects to the remote desktop. In other words shorewall needs to 'refresh' after ham0 has been created by hamachi. This will explain why I had momentary unexplained connections descibed earlier (after I had meddled with the firewall). Vncviewer uses port 5900.
I tried # /etc/shorewall/interfaces
ham ham0 -
but this came up invalid, when I ran shorewall check.
When I restart shorewall, I get 14 x "iptables: Input/output error" corresponding with the number of ports in rules.
I'm not sure how to avoid the need to restart shorewall after ham0 has been created.
Update: Ok, in the shorewall documentation (http://www.shorewall.net/manpages/sh...nterfaces.html) it mentioned that detecting broadcast is deprecated and should only be used if your iptables is supported. with that said I found a few articles explaining how to configure shorewall and hamachi and it seems like they leave the broadcast detect empty.
# I'm going to use ham as a zone name just because loc kinda confused me ;)
# in the previous post you mentioned that the following showed up as invalid...so maybe leave out the hyphen???
#zone interface broadcast
ham ham0 -
ham ham1 -
# this is what confuses me a bit but here is how I interpreted it....
# prevent traffic from ham0, ham1, etc going to other zones????
# I would feel like forwarding is required for that but oh well...
ham all REJECT:info
# same confusion....I understand ham0 -> fw and vice versa but "all"? why all, idk...
# allow traffic to ham0, ham1, etc
all ham ACCEPT
From the same link above (the first link)
ACCEPT fw net tcp 12975
# the link has a comment saying you may not need the udp rule but I think the person mixed it up...it's the udp that is used (according to the second link above) so it may be safe to leave out the tcp 12975...
ACCPET net fw udp 12975
I am still not sure about the 14 iptable i/o errors but will give it more thought.
Last edited by kenneth_phough; 01-15-2013 at 01:17 PM.