First, my first post on here, so please bear with me. I have been trying to figure this one out for several days. I have an OpenSuse 12.2 server hosted on an OpenVZ server. I am trying to setup this server up, but I have run into a problem with networking. I am able to access the server (VNC and ssh) with the firewall enabled, but am unable to send anything out (PING and Traceroute). If I disable the firewall, I am able to send traffic out (ping google.com). Does anyone know why this may be. I have tried looking at the logs to see if anything looks unusual, and I can find entries every now and then that state DROP-DEFLT. I am also unable to ping an address directly with firewall enable, but once disabled, I can. I am not a complete newb, but don’t know much about linux firewall or iptables or the such. The network device is VENET:0. Thank you to anyone who may be able to help. Please let me know if any other information is needed.
Just to be clear, which distribution is acting as the OpenVZ server
(openSUSE or another)? Also, which server is unable to ping… the OpenVZ
host or the openSUSE guest? I haven’t used OpenVZ for a while but when I
did last the guest had a modified kernel from the default.
From the guest, get the firewall information:
Code:
sudo /usr/sbin/iptables-save
#or
sudo /usr/sbin/iptables -nvL
Also you mentioned seeing DROP-DEFLT which I presume was in the
/var/log/firewall file, but if not please clarify. The default openSUSE
firewall does not block outgoing (or incoming) ICMP echo request packets
so this shouldn’t happen normally, though with the OpenVZ differences it’s
hard to say. Hopefully the commands above will provide a bit more
information.
Good luck.
On 2013-01-04 04:16, garrettgee2001 wrote:
> The network
> device is VENET:0.
Maybe you have to add that device to the firewall config file,
/etc/sysconfig/SuSEfirewall2.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
TO AB:
OpenSuse in the container (guest) OS. I am not sure what OS is running the OpenVZ, as it is not my server, but hosted by a third party, who also have no idea why this is occuring. Here is the output of the iptables command.
[LEFT]vps:~ # sudo /usr/sbin/iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
18971 44M ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0
1950 133K input_ext all – * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all – * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix "SFW2-IN-ILL-TARGET "
0 0 DROP all – * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all – * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix "SFW2-FWD-ILL-ROUTING "
Chain OUTPUT (policy ACCEPT 3665 packets, 4061K bytes)
pkts bytes target prot opt in out source destination
18971 44M ACCEPT all – * lo 0.0.0.0/0 0.0.0.0/0
Chain forward_ext (0 references)
pkts bytes target prot opt in out source destination
Chain input_ext (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG icmp – * * 0.0.0.0/0 0.0.0.0/0 icmptype 4 LOG flags 6 level 4 prefix "SFW2-INext-ACC-SQUENCH "
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0.0/0 icmptype 4
0 0 LOG icmp – * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 LOG flags 6 level 4 prefix "SFW2-INext-ACC-PING "
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 LOG 47 – * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix "SFW2-INext-ACC-IP "
0 0 ACCEPT 47 – * * 0.0.0.0/0 0.0.0.0/0
273 33192 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP "
273 33192 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5801 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP "
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5801
1639 94694 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP "
1639 94694 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901
0 0 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901 LOG flags 6 level 4 prefix "SFW2-INext-ACC "
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901
0 0 LOG tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 LOG flags 6 level 4 prefix "SFW2-INext-ACC "
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
38 4731 LOG all – * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
38 4731 DROP all – * * 0.0.0.0/0 0.0.0.0/0
Chain reject_func (0 references)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp – * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
0 0 REJECT udp – * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all – * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable
To answer the other question, yes, the DROP-DEFLT is coming from log/firewall
Like I said earlier, I don’t know hardly anything about iptables, but could it have something to do the the reject at the end of the output? Thanks again.
P.S. If i disable the firewall, all of the iptable information is cleared, and the problem exists no more, but with the firewall enabled and restarted, this is what I get by default.[/LEFT]
To Robin_Listas
I am not 100% sure where to add it, but I think you are saying add it to the correct zone, as in internal or external. If that is what you mean, I tried adding it to the external zone, but same issue. Thanks.
So it sounds like if you don’t have access to the Host, your FW modifications are on the Guest only[SUB].[/SUB]
Skimming the OpenVZ networking documentation
Common Networking HOWTOs - OpenVZ Linux Containers Wiki
When you’re configured using a VENET device, your machine is NAT behind the HostOS.
I would probably consider asking your Provider if any other machines are configured using the same address space and can “see” each other. If not sharing with any other machines <and> your network device is bound to an internal NIC (no direct exposure to the Internet), I would consider dropping the FW altogether and relying entirely on NAT for protection. You would also need to carefully evaluate what types of inbound (from Internet) access is configured on the Host, NAT by default blocks all but of course can be modified.
Otherwise, it does seem peculiar that simply enabling/disabling the FW only on the Guest should affect PING and TRACEROUTE.
Speculating, I’d be a bit surprised but suppose it’s possible that SUSE Firewall should depend on kernel modifications, but it’s almost certain that the shared kernel is a RH Enterprise, not openSUSE which IIRC is the default setup for openVZ.
IMO,
TSU
On 2013-01-04 19:26, garrettgee2001 wrote:
> Here is the output of the
> iptables command.
Please use code tags. Advanced editor, ‘#’ button.
View this
thread for instructions
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
My provider has several “hosts” and all are able to access each other via a ping or traceroute command. My VPS does have a valid external ip address. Just for kicks and giggles, I installed another version of linux (CentOS 6) and am able to ping and tracerote all day long with the iptables both enabled and disabled. My VPS is hosted on node 22 of my providers hosts. I am able to ping host22 and host 21 and host 20 and so on. My VPS is able to ping/traceroute host 22, host 21, and so on. A traceroute from my VPS to my host node (22) goes like this:My VPS IP
Node 22 Ip
A traceroute from my VPS to another node (21) of my provider goes like this
My VPS IP
Node 22 IP
Node 21 IP
I hope this is helpful and appreciate everyone’s help. Let me know if anything else is needed.
Thanks
K, I have a theory. You are either going to need to trust a lot, or
you’re going to learn some good stuff.
First, ICMP is its own thing; could you let us know if you can access
anything via TCP specifically? For example, assuming netcat is on your
VPS, try this:
netcat -zv 8.8.8.8 53 #hitting Google’s DNS service on TCP 53
netcat -zv google.com 80 #google’s web service on TCP 80
The output should be something like this:
Connection to 8.8.8.8 53 port [tcp/domain] succeeded!
Hooray, if so, that’s good. If not, well, at least it’s not just ICMP
that is misbehaving.
So now more networking; whenever you use TCP or another protocol that
expects a response packets need to come back. As you can see (it’s there,
I promise… look for OUTPUT) in your iptables rules your firewall is wide
open with outgoing stuff. Chances are very good that your packets are
actually getting out from your VPS to whatever system you are
pinging/tracerouting and that’s great… but how would you know? Well
normally you would know because your echo request would be responded-to
with an echo reply… an inbound packet. How does your system know that
this should happen? Let me show you a couple of lines from my laptop
which I do not see from your VPS:
Code:
2775K 1828M ACCEPT all – * * 0.0.0.0/0
0.0.0.0/0 ctstate ESTABLISHED
12 864 ACCEPT icmp – * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED
Basically these lines show rules which are allowing things back in from
connections that the kernel recognizes as being either ESTABLISHED in
state (for TCP stuff typically) or RELATED. My theory is that your
omission of these rules is preventing the response packets from getting
back into your system, so even though they are there your box is silently
dropping them. Want proof? LAN traces are easy, even from your VPS
assuming you can run tcpdump (I do not remember if that was possible from
back when I tried this last…) but, if not from the VPS, from anything
that you can ping or access otherwise to verify that your packets are at
least getting from your VPS to the destination somehow:
sudo /usr/sbin/tcpdump -n -s 0 -i any icmp
If you ping Google you should get something like this:
Code:
13:19:00.184986 IP 192.168.1.3 > 74.125.229.238: ICMP echo request, id
5812, seq 1, length 64
13:19:00.253597 IP 74.125.229.238 > 192.168.1.3: ICMP echo reply, id 5812,
seq 1, length 64
First line is my packet going out, and the next is the response from
Google. In your case, even with your firewall interfering, you should see
both lines (LAN tracing utilities hook in below firewalls typically, which
is good for troubleshooting); if you only see one, that’s interesting; if
you see none, that’s really bizarre and probably means the utility isn’t
working in your environment for some reason.
Anyway, poke around and see what you can see. Also, if you can get the
iptables command output from the working CentOS system that may be
interesting.
Oh, and why may this be different? My wild theory there is that the
kernel used does not support connection state stuff like the default
kernel does. Just a wild guess… try running these commands to see if
they cause rules to be added properly:
Code:
/usr/sbin/iptables -I INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
/usr/sbin/iptables -I INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
Good luck.
To AB, Thanks for the long and very informative post
For the command netcat -zv 8.8.8.8 53
Firewall Enabled
Absolutely no response
Firewall Disabled
Connection Succeeded
I think you are on to something. This is me pinging google DNS (8.8.8.8) with the tcpdump command
23:48:24.747925 IP 199.175.52.119 > 8.8.8.8: ICMP echo request, id 2611, seq 1, length 6423:48:24.770956 IP 8.8.8.8 > 199.175.52.119: ICMP echo reply, id 2611, seq 1, length 64
23:48:25.747510 IP 199.175.52.119 > 8.8.8.8: ICMP echo request, id 2611, seq 2, length 64
23:48:25.772644 IP 8.8.8.8 > 199.175.52.119: ICMP echo reply, id 2611, seq 2, length 64
23:48:26.747510 IP 199.175.52.119 > 8.8.8.8: ICMP echo request, id 2611, seq 3, length 64
23:48:26.770595 IP 8.8.8.8 > 199.175.52.119: ICMP echo reply, id 2611, seq 3, length 64
23:48:27.747137 IP 199.175.52.119 > 8.8.8.8: ICMP echo request, id 2611, seq 4, length 64
23:48:27.770668 IP 8.8.8.8 > 199.175.52.119: ICMP echo reply, id 2611, seq 4, length 64
As to these commands…
/usr/sbin/iptables -I INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
/usr/sbin/iptables -I INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
I am given a Chain/Target error.
I think you may have been right about the firewall not letting the connection back in. Also with the tcpdump, I am not able to use google.com, I have to use the IP address. So there is definitely something going on with the firewall. Now, like I said earlier. I know very little about iptables, so if you know of a rule that may be able to allow these connection back in, I would greatly appreciate it. Thank you and let me know of anything else you may need. I am going to reinstall CentOS 6 and check the iptables soon and try to get them posted. I only have access to one VPS at the moment and am having to go back and forth between the two OSes.
If it may help, I did some research on the commands I was given with “conntrack”. I actually used zypper to install conntrack-tools. I checked this before installing and got an error message.
cat /proc/net/nf_conntrack
After installing conntrack_tools, I now actually get something! Now if this is helpful, I don’t know but…
# cat /proc/net/nf_conntrack
ipv4 2 tcp 6 299 ESTABLISHED src=67.61.172.130 dst=199.175.52.119 sport=49326 dport=22 src=199.175.52.119 dst=67.61.172.130 sport=22 dport=49326 [ASSURED] mark=0 secmark=0 use=2
These show my local IP and my VPS IP and is showing my ssh connection I believe. Thanks.
Out of curiosity are things working properly now? Pending feedback on
your CentOS stuff my next step was going to figure out how to get your VPS
kernel to include the conntrack modules (which you can see on a normal
system using the /bin/lsmod command) but it looks like you thought ahead
and did that already. Anyway, try restarting your firewall, or running
those iptables commands from before to add the new rules, to see if that
helps.
Good luck.
After some further research, it appears conntrack support is not enabled in this kernel. I think the way to solve this issue to recompile the kernel, which is WAY above my head. If anyone has ANY ideas, I am willing to try anything, since as you can tell, this is not a production server. Thanks to everyone for the help and again, if you have any idea on how to enable conntrack support in the kernel I am all ears.
Edit, I do actually get a response with /proc/net/nf_conntrack without installing conntrack. Must have typed the command wrong. It’s been a long day. Sorry.
Things are still not yet working like they should. I get something strange when running /bin/lsmod. There is absolutely no output. I reinstalled CentOS 6, and here are the iptables from the install with KDE installed and vnc and SSH allowed.
[root@vps ~]# iptables --listChain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTAB LISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:s sh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5 901
REJECT all -- anywhere anywhere reject-with icmp-ho st-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-ho st-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
This version of CentOS does seem to have conntrack installed, as iptables does seem to allow support for the RELATED and ESTABLISHED states. I think it has been narrowed down to OpenSuse for OpenVZ does not have conntrack installed, which, at least to me, seems strange, as it seem like an necessary part of any OS. Thanks.
On 2013-01-05 19:26, garrettgee2001 wrote:
> This version of CentOS does seem to have conntrack installed, as
> iptables does seem to allow support for the RELATED and ESTABLISHED
> states. I think it has been narrowed down to OpenSuse for OpenVZ does
> not have conntrack installed, which, at least to me, seems strange, as
> it seem like an necessary part of any OS. Thanks.
Well, your provider is to blame for that. Ask them for support, how to
ping and elsethings, because they crapped the kernel they give you…
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
Finally figured it out. Going to do some testing and post the final results hopefully later tonight or some time tomorrow. I found what i needed on this forum (can’t take all the credit) and using the command AB gave me
/usr/sbin/iptables -I INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
/usr/sbin/iptables -I INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
I changed the command to
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
For what ever reason, conntrack does not work on this OS on openVZ but the state command does. Thank you to all that helped (and a special thanks to AB, your command got me doing the specific research I needed).
I will get an exact “tutorial” on how to fix this as soon as I can.
If anyone sees a problem with this or thinks it may cause an issuse, please let me know. Thanks.