On 08/11/17 14:28, Gordon Messmer wrote:
On 08/11/2017 11:12 AM, David A. De Graaf wrote:
What's the problem here? Why is ping more clever in finding the
route?
One problem you might have is that your ipsec gateway may have
firewall rules that allow ICMP but not other traffic to be forwarded.
Can you post the full set of firewall rules somewhere?
https://paste.fedoraproject.org/ ?
Thanks Gordon Messmer for that idea.
I had suspected the firewall, too, so read the rules with some care,
but was reluctant to turn off the firewalls, even briefly.
(The other common suspect, selinux, is disabled.)
On the remote gateway. octopus, 'ipsec -L' output was dominated by
DROP lines from 'fail2ban', but no lines included string "192.168".
Remember, autofs and ssh DO WORK between the primary gateways;
all the needed services are allowed to pass the firewall.
It's got to be a routing issue.
In 'ipsec -L -t nat' I found two entries that might be related:
MASQUERADE all -- 192.168.0.0/16 !192.168.0.0/16
MASQUERADE all -- 192.168.0.0/16 !192.168.0.0/16
These are for the convenience of VirtualBox subnets.
So I ran 'systemctl restart firewalld' which started afresh.
All the fail2ban lines were gone, as were the MASQUERADE lines.
I did the same on my local gateway, datium.
Sadly, I still get the same failures and successes.
'rpcinfo -p octopus' fails from a secondary, and succeeds from my
primary gateway, datium.
Same for 'telnet octopus 22'.
I tried to save the above files to
https://paste.fedoraproject.org/, but ordinary UNIX cut & paste
(highlight with B1, paste with B2) didn't seem to work. Sorry.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad@xxxxxxxx www.datix.us
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
