1441067142 M * Bertl_oO micah: really? incredible! :) 1441070175 M * micah it will take a while before it disappears entirely (ie. it wont be removed from existing stable) 1441073219 J * klaus 6cc99cea@107.161.19.53 1441073233 N * klaus klaus_ 1441073236 M * klaus_ hi there 1441073267 M * klaus_ anyone around to help explain a vserver problem? i don't see the issue covered on the wiki and it's breaking my brain. 1441073412 M * klaus_ basically, if i'm inside the guest, if i ping a host on a different network, i can see the packets going out (via tcpdump on the host), but none of them are coming back. 1441073435 M * klaus_ on a different guest on the same host, if i ping the same remote system, i can see the traffic coming in and out as expected. 1441073442 M * klaus_ same scenario from the host itself also works 1441073478 M * klaus_ and i can ping the problem guest from the remote system 1441073735 M * klaus_ anyone? 1441074484 M * Bertl_oO most likely a configuration issue 1441074578 M * Bertl_oO first check if a ping on the host with the guest IP (i.e. with -I ) doesn't fail as well 1441074606 M * Bertl_oO if that fails, your routing and/or firewall is to blame 1441074847 M * klaus_ ah, ping from the host but set the source ip to that of the affected guest? 1441075018 M * Bertl_oO yep, precisely 1441075217 M * klaus_ okay, so that works 1441075237 M * klaus_ ping -I 1441075251 M * Bertl_oO virtual interface? 1441075259 M * Bertl_oO are you using network namespaces? 1441075271 M * klaus_ i'm not sure. how would i check that? 1441075293 M * Bertl_oO well, if you don't know, it's unlikely you do 1441075311 M * Bertl_oO and in this case, there is no "virtual interface" 1441075345 M * Bertl_oO i.e. you are most likely using IP isolation (the default) which simply restricts a guest to a set (or a single) IP address 1441075379 M * Bertl_oO when you are inside the guest, "ip a l" will show you the guest IPs 1441075415 M * Bertl_oO you can then use those IPs for testing with ping -I 1441075474 M * klaus_ okay, so that gets a response as expected 1441075541 M * Bertl_oO then try the same command inside the guest 1441075566 M * klaus_ that works, too. 1441075580 M * Bertl_oO see, so the guest is using a different IP then 1441075591 M * Bertl_oO i.e. not the one you suspected 1441075602 M * klaus_ how odd. 1441075628 M * Bertl_oO double check with tcpdump on the host or strace inside the guest 1441075642 M * Bertl_oO (in the failure case) 1441075699 M * klaus_ ah yeah, tcpdump looks like it's using the other interface address as the default. 1441075717 M * Bertl_oO then repeat the test(s) with that one 1441075832 M * klaus_ i know the other guest's address won't work -- one is Internet, the other is internal RFC network 1441075848 M * klaus_ i am not sure why it's trying to pass the internal traffic over the internet interface, though 1441075862 M * klaus_ is it a mistake of interface order, or route order? 1441075885 M * Bertl_oO depends on the setup 1441075908 M * Bertl_oO the first IP assigned to a guest will be used as a default, if there is no clear route 1441075936 M * klaus_ so in our setup, eth0 is our internal, eth1 is our Internet 1441075964 M * Bertl_oO if there is a routing entry which matches the guests request and the IP which is selected as source is part of the IP set assigned to the guest, that this IP will be selected 1441075993 M * Bertl_oO s/that/then/ 1441076051 M * klaus_ hrm, that doesn't seem to be happening. 1441076167 M * Bertl_oO how so? 1441076237 M * klaus_ so, the default route is via the internet interface 1441076247 M * klaus_ then there is a 10/8 route through the RFC interface 1441076274 M * klaus_ with the address of a host on the RFC interface's VLAN as the gateway 1441076309 M * Bertl_oO gateway to where? 1441076322 M * klaus_ 10/8 1441076326 M * klaus_ let me scrub and paste 1441076543 M * klaus_ sent you a pastebin link 1441076576 M * klaus_ AAA.BBB.CCC.0 is on the same network as AAA.BBB.CCC.DDD 1441076698 M * Bertl_oO the other way round :) 1441076717 M * klaus_ er, yeah. sorry :-) 1441076746 M * Bertl_oO well, unusual setup, but I don't see a problem here, have you tried with something else but ping? 1441076768 M * klaus_ ssh, telnet, nc, yeah, same result. :/ 1441076796 M * Bertl_oO what IPs are assigned to the guest? 1441076939 M * klaus_ the guest has an RFC address of 10.3.28.149/32 on eth0 1441076973 M * Bertl_oO /32 so it isn't on a network 1441077016 M * Bertl_oO i.e. it will use the fallback to reach anything 1441077029 M * klaus_ hrm. so the mask is too restrictive? 1441077042 M * Bertl_oO in your case yes 1441077076 M * Bertl_oO try with /22, which matches your network setup 1441077104 M * klaus_ k, lemme see if we can do that ... 1441077125 M * klaus_ would that be changed via the host or on the guest? i'm presuming the host? 1441077201 M * Bertl_oO yes, you need to adjust the guest config 1441077219 M * Bertl_oO make sure to take the guest down first, then change the config and then bring it up again 1441077247 M * klaus_ ok 1441077251 M * Bertl_oO otherwise the "wrong" IP/mask will stay around causing confusion 1441077252 A * klaus_ digs in 1441077568 M * klaus_ okay, so that looks normal again 1441077762 M * klaus_ i'm assuming the internet interface on the guest should also use a prefix matching that of the host? 1441077776 M * klaus_ (i just tested changing the guest's internal interface) 1441077777 M * Bertl_oO yes, that is preferable 1441077816 M * Bertl_oO i.e. there is no good reason to use different netmasks 1441078057 M * Bertl_oO okay, I'm off to bed now ... have fun! 1441078066 N * Bertl_oO Bertl_zZ 1441078165 M * klaus_ thanks a lot, Berti! 1441080825 Q * klaus_ Quit: http://www.kiwiirc.com/ - A hand crafted IRC client 1441081757 Q * zerick Quit: No Ping reply in 180 seconds. 1441081768 J * zerick ~zerick@irc.quassel.zerick.me 1441085900 J * Ghislain ~aqueos@adsl2.aqueos.com 1441086857 Q * transacid Remote host closed the connection 1441087257 J * transacid ~transacid@transacid.de 1441091127 Q * derjohn_mob Ping timeout: 480 seconds 1441091561 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1441092756 J * derjohn_mob ~aj@fw.gkh-setu.de 1441095106 M * Ghislain hi there 1441096708 M * Gremble hi Ghislain 1441098036 Q * derjohn_mob Ping timeout: 480 seconds 1441098542 J * derjohn_mob ~aj@fw.gkh-setu.de 1441098762 Q * Guy- Ping timeout: 480 seconds 1441098873 J * Guy- ~korn@elan.rulez.org 1441104188 N * Bertl_zZ Bertl 1441104190 M * Bertl morning folks! 1441108760 Q * fstd Remote host closed the connection 1441108772 J * fstd ~fstd@xdsl-87-78-18-130.netcologne.de 1441109768 N * Bertl Bertl_oO 1441113927 Q * derjohn_mob Ping timeout: 480 seconds 1441114514 J * derjohn_mob ~aj@fw.gkh-setu.de 1441115564 Q * Aiken Remote host closed the connection 1441116227 Q * Gremble Ping timeout: 480 seconds 1441118102 Q * derjohn_mob Ping timeout: 480 seconds 1441118620 J * derjohn_mob ~aj@fw.gkh-setu.de 1441122687 J * bonbons ~bonbons@2001:a18:20c:4701:7cc0:3ab6:96fc:e1d8 1441123084 J * Vudumen ~vudumen@perverz.hu 1441123348 J * Ghislain1 ~aqueos@adsl2.aqueos.com 1441123348 Q * Ghislain Read error: Connection reset by peer 1441123572 Q * Vudumen Ping timeout: 480 seconds 1441123825 J * Vudumen ~vudumen@perverz.hu 1441130520 J * arekm ~arekm@ixion.pld-linux.org 1441130576 Q * arekm_ Remote host closed the connection 1441131652 Q * derjohn_mob Ping timeout: 480 seconds 1441136486 J * Aiken ~Aiken@d63f.h.jbmb.net 1441140761 J * derjohn_mob ~aj@p578b6aa1.dip0.t-ipconnect.de 1441143956 Q * bonbons Quit: Leaving 1441144013 Q * Ghislain1 Quit: Leaving. 1441144014 J * Ghislain ~aqueos@adsl2.aqueos.com 1441144497 Q * Ghislain Ping timeout: 480 seconds 1441146812 Q * derjohn_mob Remote host closed the connection 1441146972 J * derjohn_mob ~aj@p578b6aa1.dip0.t-ipconnect.de 1441151961 Q * fstd Remote host closed the connection 1441151972 J * fstd ~fstd@xdsl-84-44-223-189.netcologne.de