[gentoo-user] Routing issue with OpenVPN and internal DNS

2018-12-03 Thread Bill Kenworthy
On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i.e. not existing) connections?
> ...


sent too soon, missed some ...


As its a router, have you correctly configured openvpn's
client-to-client, CCD and iroute setup?


Google "openvpn networks behind server"


BillK







Re: [gentoo-user] Routing issue with OpenVPN and internal DNS

2018-12-03 Thread Bill Kenworthy
On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i.e. not existing) connections?
> ...


As its a router, have you correctly configured openvpn's
client-to-client setup?


BillK






Re: [gentoo-user] Routing issue with OpenVPN and internal DNS

2018-12-03 Thread Andrew Udvare
On 03/12/2018 09:49, Michael Orlitzky wrote:
> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>
>> iptables on server:
>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>> NEW -j ACCEPT
>>
> 
> Is that only forwarding packets for new (i.e. not existing) connections?

Not sure but I do have a rule with using --ctstate ESTABLISHED,RELATED
like yours. I even got rid of the interface argument in case that's a
problem. The box is a router and has 2 NICs going, one for WAN and one
for LAN. enp1s0f0 being the internet, and enp1s0f1 is for 192.168.1.0/24

When I'm connected to the VPN and I'm definitely not on my network, I
can do things like `ssh 192.168.1.xxx` and it works. And HTTP works too.
It's only port 53 that I am having trouble with.

dnsmasq (listening only on enp1s0f1, 192 address) gets the request from
the tun0 interface, which seems to route correctly to the 192 address.
The response that dnsmasq creates (presumably) does not route back to
the originating IP.

Happy to provide any other configuration details and packet dumps if it
helps.

Full iptables (I use a script to reset to sane state, suggestions welcome):

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-N SCANS
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state
--state NEW -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name BLACKLIST --mask 255.255.255.255 --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--update --seconds 10 --hitcount 10 --rttl --name BLACKLIST --mask
255.255.255.255 --rsource -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9222 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p udp -m udp --dport 68 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p udp -m udp --dport 33434:33523 -j REJECT --reject-with
icmp-port-unreachable
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 3306 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m conntrack --ctstate NEW,ESTABLISHED
-m udp --dport 137 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m conntrack --ctstate NEW,ESTABLISHED
-m udp --dport 138 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED
-m tcp --dport 139 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED
-m tcp --dport 445 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4242 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i enp1s0f1 -p udp -m udp --dport 5353 -m
conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 12112 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 205.171.2.64/32 -p ipv6 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -i enp1s0f1 -j ACCEPT
-A FORWARD -i enp2s0 -j ACCEPT
-A FORWARD -i enp1s0f0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.100.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j
DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
-A SCANS -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
-A SCANS -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG -j DROP
-A SCANS -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A SCANS -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

iptables -nat --list-rules:

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.100.0.0/24 -j MASQUERADE
-A POSTROUTING -j MASQUERADE
-A DOCKER -i docker0 -j 

Re: [gentoo-user] Routing issue with OpenVPN and internal DNS

2018-12-03 Thread Michael Orlitzky

On 12/3/18 5:55 AM, Andrew Udvare wrote:


iptables on server:
-A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j 
ACCEPT



Is that only forwarding packets for new (i.e. not existing) connections?

Ours looks like,

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s $INSIDE_NET-j ACCEPT
iptables -A FORWARD -i $VPN_INTERFACE -j ACCEPT

(and you need to enable the net.ipv4.ip_forward sysctl)



[gentoo-user] Routing issue with OpenVPN and internal DNS

2018-12-03 Thread Andrew Udvare
Very confused here, but I feel like I'm missing a route on either the client 
side or the server side. Or it is a firewall rule but that doesn't seem likely.

My OpenVPN server/client config is almost identical to that on the wiki page: 
https://wiki.gentoo.org/wiki/OpenVPN#Configuration

After connecting from another ISP and then connecting to the VPN, I use dig to 
query the internal server:

dig @192.168.1.254 pi.hole

The server can see the DNS request from the client:

 # tcpdump -i tun0 'port 53'
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
02:21:07.996606 IP 10.100.0.6.50312 > 192.168.1.254.domain: 13933+ [1au] A? 
pi.hole. (36)

Even the dnsmasq log is showing the request:

Dec  3 10:21:45 dnsmasq[1026]: 4744 71.214.144.51/49349 query[A] pi.hole from 
71.214.144.51
^ shows the external IP. Is this normal?

On the client side, dig times out.

So if it can come through client-to-server but won't go back server-to-client, 
where could the issue be?

I even changed the iptables policies for INPUT and FORWARD to allow to see if 
anything would change but the result was the same.

I have HTTP running on the server and accessing via the IP works fine:

 $ curl https://192.168.1.254 -k
...
< Server: nginx
< Date: Mon, 03 Dec 2018 10:22:45 GMT
< Content-Type: text/html
< Content-Length: 574
< Connection: keep-alive
< Keep-Alive: timeout=20

OpenVPN server configuration relevant lines:

# OpenVPN 'virtual' network infomation, network and mask
server 10.100.0.0 255.255.255.0
push "redirect-gateway def1"
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.254"

Routing table on server:
 $ route -4
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
default xx-xx-xx-xx.0.0.0.0 UG1024   00 enp1s0f0
10.100.0.0  10.100.0.2  255.255.255.0   UG0  00 tun0
10.100.0.2  0.0.0.0 255.255.255.255 UH0  00 tun0
xx.xxx.144.00.0.0.0 255.255.255.0   U 0  00 enp1s0f0
xx-xxx-144-254. 0.0.0.0 255.255.255.255 UH1024   00 enp1s0f0
172.17.0.0  0.0.0.0 255.255.0.0 U 0  00 docker0
192.168.1.0 0.0.0.0 255.255.255.0   U 0  00 enp1s0f1

iptables on server:
-A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j 
ACCEPT

-t nat:
-A POSTROUTING -s 10.100.0.0/24 -j MASQUERADE

On the client (en0 is the wifi, utun4 is created by OpenVPN):
 $ netstat -nrtf inet
Routing tables

Internet:
DestinationGatewayFlagsRefs  Use   Netif Expire
0/110.100.0.5 UGSc   840   utun4
default172.20.10.1UGSc30 en0
10.100.0.1/32  10.100.0.5 UGSc00   utun4
10.100.0.5 10.100.0.6 UHr140   utun4
71.214.144.51/32   172.20.10.1UGSc10 en0
127127.0.0.1  UCS 00 lo0
127.0.0.1  127.0.0.1  UH  5   140998 lo0
128.0/110.100.0.5 UGSc40   utun4
169.254link#9 UCS 00 en0  !
172.20.10/28   link#9 UCS 10 en0  !
172.20.10.1/32 link#9 UCS 20 en0  !
172.20.10.1b2:70:2d:2:18:64   UHLWIir 8   23 en0   1184
172.20.10.3/32 link#9 UCS 00 en0  !
172.20.10.15   ff:ff:ff:ff:ff:ff  UHLWbI  0   18 en0  !
192.168.1  10.100.0.5 UGSc00   utun4
224.0.0/4  link#9 UmCS20 en0  !
224.0.0.2511:0:5e:0:0:fb  UHmLWI  00 en0
239.255.255.2501:0:5e:7f:ff:faUHmLWI  04 en0
255.255.255.255/32 link#9 UCS 00 en0  !

-- 
Andrew Udvare