[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Network issues with SuSE firewall
On Fri, Nov 07, 2003 at 10:03:41PM +0000, Ian Pratt wrote: > > First, I noted that xen_nat_enable was *not* built along with the > > other tools in xeno-clone/install/bin. Is this still needed (per the > > README.CD instructions, for a NAT-based virtual host, rather than > > IP-based)? > > It's a script rather than a binary. Yes....I was just worried about versioning, as we've been warned with the xi_ programs. > The current 'loop through domain0' approach to NAT is not the > long term solution (we're adding NAT to Xen). > > I'm afraid I'm not entirely surprised that xen_nat_enable doesn't > play well with your firewall. I'll do a little more diagnosis in the future. What I think happened, though, is that the NAT's nat* rules somehow discarded the filter* rules. I was also getting some complaints about mangle* needing to load the iptables module, which was not found (this was when I was trying to re-add my default rules). iptables is a big pain, no matter what. But adding nat* rules (especially when there were none in the first place) seems like it should work. > Are you short of IP addresses? I'd certainly recommend using one > IP per guest for the moment unless you really have to use NAT. Of > course, you don't need to use NAT if you only want to do > inter-guest communication (you can use the 169.254.1.X addresses > directly). 1) Yes, I'll have IP addresses to play with, but don't yet as of today. 2) Hmmm -- this does not work. Any quick guess what to try fixing? $ xenctl domain list id: 0 (Domain-0) processor: 0 has cpu: true state: 0 active mcu advance: 10 total pages: 192000 id: 2 (XenoLinux) processor: 0 has cpu: false state: 1 stopped mcu advance: 10 total pages: 24576 $ ifconfig eth0:0 eth0:0 Link encap:Ethernet HWaddr 00:B0:D0:DF:FA:ED inet addr:169.254.1.0 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 $ ping -c1 169.254.1.0 PING 169.254.1.0 (169.254.1.0) from 169.254.1.0 : 56(84) bytes of data. 64 bytes from 169.254.1.0: icmp_seq=1 ttl=64 time=0.083 ms --- 169.254.1.0 ping statistics --- 1 packets transmitted, 1 received, 0% loss, time 0ms rtt min/avg/max/mdev = 0.083/0.083/0.083/0.000 ms $ ping -c1 169.254.1.1 PING 169.254.1.1 (169.254.1.1) from 169.254.1.0 : 56(84) bytes of data. [times out] --- 169.254.1.1 ping statistics --- 1 packets transmitted, 0 received, 100% loss, time 0ms I saw nat* rules for this, also for port 2201. But now I re-ran xen_nat_enable and locked myself out again. I'll reboot, and look some more, but meanwhile maybe you can tell me: - Should 169.254.1.1 be ping-able from 169.254.1.0 ? - Do I "ssh -p2201 root@xxxxxxxxxxx" or "ssh -p2201 root@xxxxxxxxxxx" or "ssh -p2201 root@localhost" or the native IP address (137. ...) Finally, and this concludes today's confusion: I seem unable to get any sort of console output after the kernel boots. I redirected with "console=xencons0", but even after NAT, don't get anything. /dev/tty0 didn't seem any different. I'd *really* like to redirect to a file, or to the physical console (tty0). I suspect this is another firewall issue with console messages via UDP & NAT, but if there is a workaround to get it sent to a file I'd greatly prefer it. Ok, one more random question: I noted that the new domain wanted an initrd.gz, but I did not get a new one in the xeno-clone tree. "mkinitrd -k image.gz -i initrd.gz" failed ("couldn't find modules"). I copied the initrd from the CD and it seems to work, but it might not forever. > > I copied & ran the xen_nat_enable from the CD, and immediately was > > unable to access my machine to/from the network (I had already run > > "ifconfig eth0:0 169.254.1.0 up"). > > > > What I found was that the SuSEfirewall default configuration did not > > get along well with whatever changes to iptables were made by > > xen_nat_enable. My solution, which needs to be tuned later, was to > > edit /etc/sysconfig/SuSEfirewall2 to greatly loosen the firewall. I > > then restarted it: > > Another thing to watch out for is that some distributions > 'helpfully' create random link-local 169.254.x.x addresses for > all interfaces automatically. This doesn't play well with our use > of link-local addresses. e.g. you have to nail this in RH9 with ZEROCONF=NO > in ifcfg-eth0 I'm using SuSE, which doesn't seem to do this. However, the SuSE setup for iptables is *really* much more difficult than for RedHat. They obfuscate it in multiple layers of scripts and stuff... -- Greg ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |