| sicelo | networking SOS please :-) | 15:52 |
|---|---|---|
| bencoh | ? | 15:53 |
| bencoh | lemme guess - you need a tunnel/vpn of some sort? | 15:53 |
| sicelo | https://paste.debian.net/1222770/ | 15:54 |
| bencoh | ah, nevermind :) | 15:54 |
| sicelo | i have the scenario in this paste - is there anything i could/should do to make pings work from wlan0 to lxcbr0 ? | 15:54 |
| bencoh | from wlan0 to lxcbr0? | 15:55 |
| bencoh | I don't think ping -I wlan0 does what you expected | 15:55 |
| sicelo | yes :-( | 15:56 |
| bencoh | you basically want to test if your lxc container is reachable from another computer connected to the wifi network? | 15:56 |
| sicelo | it sends it out the default gw, which of course doesn't know about 10.0.3.0/24 network | 15:56 |
| sicelo | bencoh: yes, something like that :-) | 15:56 |
| bencoh | you'll need a bit more than just ip_forward then | 15:57 |
| sicelo | not masquerade, i hope :-/ | 15:57 |
| bencoh | if you only want lxc->world, then masquerade | 15:58 |
| bencoh | (it's not that hard) | 15:58 |
| bencoh | if you also want world->lxc, then you need to NOT use nat/masquerade, AND setup routes both ways | 15:58 |
| bencoh | but first you also need to set /proc/sys/net/ipv4/conf/eth0/forwarding for every interface involved | 15:58 |
| bencoh | in your case, lxc0 and wlan0 | 15:58 |
| bencoh | and you need to set routes both ways, ie the remote computer needs to know how to reach the lxc | 15:59 |
| sicelo | right. maybe let me ask the real question (i was simplifying a bit here, because of a quick test i made on my laptop) | 16:00 |
| bencoh | (or the router, if you intend to connect your lxc to the world without masquerading on the laptop) | 16:00 |
| sicelo | bencoh: https://paste.debian.net/1222775/ | 16:03 |
| sicelo | i want that .106 to be pingable from the internet. .105 is pingable, and ISP routes the .104/29 block to this router. so ISP part seems ok | 16:04 |
| bencoh | you need a static route on the router | 16:05 |
| sicelo | i don't have access to .106 (maybe they have wrong gw set, or something). what i need is to be sure that there's no mistake in the way things are configured in this router | 16:05 |
| bencoh | and set that address on one of the computers | 16:05 |
| bencoh | (at least that's one way of doing it) | 16:05 |
| sicelo | you need a static route on the router .... static route pointing to? | 16:06 |
| sicelo | i'm asking because there is a route in the router for the .104/29 network | 16:21 |
| bencoh | ah nevermind | 16:33 |
| bencoh | I missed the fact that the /29 is routed to the lan | 16:34 |
| bencoh | who is .106? | 16:34 |
| sicelo | a Fortigate Firewall. i have no access to it. (actually i work for the ISP ... so my jurisdiction stops at the router. client says they can't do GRE tunnels in their firewall because we're blocking stuff. but we're not) :-) | 16:36 |
| bencoh | at that point I'd tcpdump on mikrotik and make sure packets from the outside are properly forwarded toward .106 | 16:37 |
| sicelo | i asked their tech guy to plug in a laptop on that ether3, and set it to have .106. it didn't make a difference (although now i can't be sure if he did it right) | 16:37 |
| bencoh | at least something pings | 16:38 |
| sicelo | unfortunately he was also in a rush (covid scare in their office), so we couldn't do further tests. what i don't understand is why i can't ping the .106 from within the router if i specify src address to be the 75.54. | 16:39 |
| sicelo | i *think* the router should 'see' that the requested address is already routed in local table, so no need to send it to default gw | 16:40 |
| sicelo | anyway, i'm trying to be absolutely sure this router is correctly configured | 16:40 |
| bencoh | linux has a setting to drop packets with a dst addr not matching the interface address | 16:42 |
| bencoh | it might be enabled on your mikrotik | 16:42 |
| bencoh | (although I don't know how it would behave on interface with forwarding enabled) | 16:43 |
| sicelo | i should think since the Mikrotik is specifically meant to operate as a router, those settings default to the right thing | 16:45 |
| sicelo | but yes, thanks for checking | 16:45 |
| bencoh | anyway I'd still just tcpdump on mikrotik | 16:46 |
| bencoh | and try pinging from the outside | 16:46 |
| bencoh | just to make sure packets go out, and that you don't get any answer | 16:46 |
| sicelo | i did. let me see if i can share a paste | 16:46 |
| sicelo | bencoh: https://paste.debian.net/1222781/ | 16:48 |
| bencoh | and no answer? | 16:50 |
| bencoh | well then ... | 16:50 |
| bencoh | looks like the fortigate filters traffic (?) | 16:51 |
| sicelo | it does respond when pinged from .105 though | 16:53 |
| bencoh | which is why I said it's probably filtering | 16:53 |
| sicelo | and ping also didn't work when a laptop was connected instead of firewall (assuming it was configured correctly) | 16:54 |
| sicelo | i didn't to a tcpdump at that time though, unfortunately | 16:54 |
| sicelo | s/to/do/ | 16:54 |
| sicelo | i do think the problem is on their side (firewall). just wanted to be sure i'm not the one with bad config to begin with :-) | 16:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!