EvilZone
Hacking and Security => Hacking and Security => Topic started by: lucid on August 25, 2014, 10:46:15 PM
-
Ok seriously what the fuck. I've been working with this for awhile now and nothing has any change at all. I have an Arch box running as a DNS/DHCP server + firewall for a bunch of VMs. The VMs are on subnet 10.10.6.0 and the Arch gateway is on the 192.168.0.0 subnet. I have a static route set up so that all computers on 192.168.0.0 can 'see' 10.10.6.0 and vice versa. Until this point there was no problems and everything worked.
The symptoms:
- Everything works fine on the VMs for a minute or so, then the connection will drop and it will only be able to ping things on it's subnet(10.10.6.x), not including the gateway(10.10.6.1)
- When I troubleshoot, I find that it's a DNS issue. It seems that the VMs will intermittently fail to elicit a response from the DNS server. The connection goes down for around a minute, then comes back on for around a minute.
I've already turned off the firewall to make sure, and sure enough the internet is fine without it. So it's definitely something wrong with my firewall. So I'll show you:
# Generated by iptables-save v1.4.21 on Mon Aug 25 15:18:28 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [1:89]
:OUTPUT ACCEPT [0:0]
:tcp_packets - [0:0]
:udp_packets - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp_packets
-A INPUT -p udp -m conntrack --ctstate NEW -j udp_packets
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -d 10.10.6.0/24 -i vboxnet0 -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
-A FORWARD -s 10.10.6.0/24 -o vboxnet0 -p udp -m multiport --dports 53,67 -j ACCEPT
-A tcp_packets -p tcp -m multiport --dports 80,443,12444 -j ACCEPT
-A tcp_packets -p tcp -j DROP
-A udp_packets -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
COMMIT
# Completed on Mon Aug 25 15:18:28 2014
I realize it's not the best firewall ever, but please try and only give criticism related to the problem at hand. Also, I'm almost 100% sure it's something wrong with the FORWARD chain. Thanks.
EDIT: Ok now it seems it's a problem with the Win7 VM only. I have an XP and a Xubuntu VM that both work perfectly fine, even when the Win7 can't ping anything outside of it's subnet. Hmm, I wonder why though.
-
You probably figured this out by now... If so, I am curious to know what the problem was.
The only thought that came to mind when I was reading this was to add a -j target of LOG for each of the FORWARD rules. That way you could at least see the fate of those packets.
-
I can't quite remember, but I believe it had less to do with the firewall rules and more to do with the fact that I had one laptop acting as a gateway for quite a few VMs and there was latency.
-
Ok seriously what the fuck. I've been working with this for awhile now and nothing has any change at all. I have an Arch box running as a DNS/DHCP server + firewall for a bunch of VMs. The VMs are on subnet 10.10.6.0 and the Arch gateway is on the 192.168.0.0 subnet. I have a static route set up so that all computers on 192.168.0.0 can 'see' 10.10.6.0 and vice versa. Until this point there was no problems and everything worked.
The symptoms:
- Everything works fine on the VMs for a minute or so, then the connection will drop and it will only be able to ping things on it's subnet(10.10.6.x), not including the gateway(10.10.6.1)
- When I troubleshoot, I find that it's a DNS issue. It seems that the VMs will intermittently fail to elicit a response from the DNS server. The connection goes down for around a minute, then comes back on for around a minute.
I've already turned off the firewall to make sure, and sure enough the internet is fine without it. So it's definitely something wrong with my firewall. So I'll show you:
# Generated by iptables-save v1.4.21 on Mon Aug 25 15:18:28 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [1:89]
:OUTPUT ACCEPT [0:0]
:tcp_packets - [0:0]
:udp_packets - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp_packets
-A INPUT -p udp -m conntrack --ctstate NEW -j udp_packets
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -d 10.10.6.0/24 -i vboxnet0 -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
-A FORWARD -s 10.10.6.0/24 -o vboxnet0 -p udp -m multiport --dports 53,67 -j ACCEPT
-A tcp_packets -p tcp -m multiport --dports 80,443,12444 -j ACCEPT
-A tcp_packets -p tcp -j DROP
-A udp_packets -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
COMMIT
# Completed on Mon Aug 25 15:18:28 2014
I realize it's not the best firewall ever, but please try and only give criticism related to the problem at hand. Also, I'm almost 100% sure it's something wrong with the FORWARD chain. Thanks.
EDIT: Ok now it seems it's a problem with the Win7 VM only. I have an XP and a Xubuntu VM that both work perfectly fine, even when the Win7 can't ping anything outside of it's subnet. Hmm, I wonder why though.
Can you show me the static route setup?
Btw you could let the router do the routing.
Also nice to see you having all this shit setup and running and shit.
Keep it up.
-
I do have the router do the routing actually. I currently don't have this problem, this got necro'd by the above poster, but I am ok with it because he had a legitimate question about the topic for knowledge and learning purposes.
Thanks, I'll be getting the rest of the stuff I need to finish setting up everything. Finally...