Reputation
Top tag
Next privilege 100 Rep.
Edit community wikis
Badges
1 9
Impact
~12k people reached

  • 0 posts edited
  • 0 helpful flags
  • 1 vote cast
Feb
12
awarded  Popular Question
Dec
15
awarded  Popular Question
Jan
15
awarded  Notable Question
Nov
17
awarded  Self-Learner
Sep
29
awarded  Popular Question
Apr
4
comment Pings from VPN network to VPN client work; pings into from VPN client to VPN network fail - why?
@aseq - in this example x.x.x.x was the gateway of the VPN server (I have masked the actual address). 10.11.11.1 is a gateway to another 10.x.x.x network but wasn't a useful gateway to the network I needed to reach. So, 10.11.11.7 needed to route responses back to 10.8.0.22 via 10.11.11.2 (the VPN server). As it was, an adapter specific route was causing these packets to flow to 10.11.11.1 which was the wrong way to redirect them.
Apr
4
accepted Pings from VPN network to VPN client work; pings into from VPN client to VPN network fail - why?
Mar
15
revised Why is a ping response being sent to the wrong gateway?
added 688 characters in body
Mar
14
awarded  Supporter
Mar
14
answered Why is a ping response being sent to the wrong gateway?
Mar
14
awarded  Teacher
Mar
14
revised Why is a ping response being sent to the wrong gateway?
added 304 characters in body
Mar
14
answered Pings from VPN network to VPN client work; pings into from VPN client to VPN network fail - why?
Mar
14
awarded  Scholar
Mar
14
accepted Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
Mar
14
comment Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
Cool bananas, that did the trick - thanks!
Mar
14
comment Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
Ok, so this perhaps has provided the answer: /etc/sysconfig/network-scripts/route-eth0 has an entry of this kind: default table route_eth0 via 10.11.11.1 dev eth1 I suspect if I edit that to be 10.11.11.2 I'll get the desired behaviour without the arp hack. Let's see!
Mar
14
comment Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
Mmmm. Ok, so perhaps policy based routing is a factor here. When I run ip rule show, I get this: 0: from all lookup 255 32764: from 10.11.11.2 lookup route_eth1 32765: from 170.225.161.18 lookup route_eth0 32766: from all lookup main 32767: from all lookup default How do I inspect these tables, I wonder?
Mar
14
comment Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
Thanks. As far as I know, in my particular case, there is no source based routing configured anywhere on the hosts (client, VPN server, LAN server) in my domain, so I don't think this explains the issue.
Mar
14
revised Under what circumstances will Linux ignore the route table when choosing the MAC address for an outbound frame?
added 425 characters in body