On 11/02/16 16:24, John Hayden wrote:
David,
Thanks for the information. Pinging works fine. The trouble I am
having is with ssh. After making my vpn connection, I can ssh into the
vpn server but I cannot ssh directly to any other server behind the vpn
server.
Right. If you can ping that host behind the VPN server but cannot SSH,
then it is a firewall issue. If there had been a routing issues, ping
wouldn't have worked at all.
Then you can tweak the tcpdump command slightly and see where things
stop. So on the VPN server run:
# tcpdump -ni enp3s0 net 10.200.0.0/24 and port 22
If you see nothing, then it is the rule set on your VPN server which
blocks this traffic. If you see only traffic from the VPN but no
response, then it is the firewall on the remote server.
I am not using iptables but firewalld. I would like to get this
to work with firewalld but can’t quite figure out what is going on
Okay, some details. Firewalld uses iptables under the hood. So
iptables-save can provide all the needed information for us to help you
debugging what goes wrong.
--
kind regards,
David Sommerseth
>> On Feb 11, 2016, at 5:07 AM, David Sommerseth
>> <dsommers@fedoraproject.org
mailto:dsommers@fedoraproject.org> wrote:
>>
>> [re-send with proper sender address - sorry]
>>
>> On 11/02/16 00:05, John Hayden wrote:
>>> I have an openvpn server set up on a Centos 7 box running
>>> firewallD. It seems to be working well except for one problem.
>>>
>>> Some scenarios:
>>>
>>> Client (etho 192.168.1.x, tun0 10.201.0.6) ———————————>VpnServer
>>> (enp4s0 faces internet, enp3s0 internal with 10.200.0.1/16 and tun0
>>> internal with 10.201.0.1/16)
>>>
>>> Connection from Client -> VpnServer — Good Client ping —> both
>>> 10.200.0.1 and 10.200.0.10 — Good Client ssh —> 10.200.0.1 —
>>> Good Client ssh —> to another server on the 10.200.0.0/16 network —
>>> connection refused
>>
>> This can be a routing issue just as much as a firewall issue, and it
>> may be on both your openvpn server as well as the other box in you
>> 10.200.0.0/16 net. So we need to eliminate a few things first.
>>
>> 0) I presume IPv4 forwarding is enabled ('sysctl net.ipv4.ip_forward'
>> should return 1)
>>
>> 1) Have a look at both the tun0 and enp3s0 interfaces using tcpdump.
>> See if the traffic stops somewhere when you're doing ping. You should
>> see both ICMP echo request and replies on both interfaces.
>>
>> # tcpdump -ni enp3s0 icmp
>>
>> If you have much traffic going on, you can reduce it further:
>>
>> # tcpdump -ni enp3s0 icmp and net 10.200.0.0/24
>>
>> This should provide only ICMP packets coming from/going to the VPN
>> interface.
>>
>> 2) If you see ICMP echo requests entering enp3s0 but no ICMP echo
>> replies, it may indicate either a firewall issue on the VPN server or
>> the destination computer - or, just as likely, issues with a return
>> route on your destination computer. Return routes are important if
>> your VPN server is not on your default gateway, or before your gateway.
>>
>> In the OpenVPN community we also often point people to this
>> troubleshoot helper:
http://pekster.sdf.org/misc/serverlan.png
>> When using this one it usually helps to have temporarily turned off
>> the firewall, to get the basic networking working before protecting it
>> with iptables.
>>
>> I hope this can help you in the right direction of debugging. If
>> everything works without firewalls enabled, then it would be useful to
>> see the output of iptables-save (pastebin or attachment) with your
>> ruleset loaded.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>>
>>
>>
>>> On the VpnServer I have enp4s0 in the external zone enp3s0 and tun0
>>> in the internal zone along with ssh turned on on the internal zone
>>>
>>> Here is my routing table on the VpnServer (public ip obscured)
>>>
>>> netstat -r Kernel IP routing table Destination Gateway
>>> Genmask Flags MSS Window irtt Iface default
>>> 207-xxx-xxx-169 0.0.0.0 UG 0 0 0 enp4s0
>>> default 10.200.0.1 0.0.0.0 UG 0 0
>>> 0 enp3s0 10.200.0.0 0.0.0.0 255.255.0.0 U
>>> 0 0 0 enp3s0 10.201.0.0 10.201.0.2 255.255.255.0
>>> UG 0 0 0 tun0 10.201.0.2 0.0.0.0
>>> 255.255.255.255 UH 0 0 0 tun0 207.xxx.xxx.168
>>> 0.0.0.0 255.255.255.248 U 0 0 0 enp4s0
>>>
>>> I’m not sure if its a routing issue or a firewall issue (I’m
>>> leaning towards the latter) but when I turn off firewalld,
>>> everything seems to work ok.
>>>
>>> Anybody have any clues or insight?
>>>
>>> Thanks in advance
>>>
>>> John Hayden
>>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
