I have somewhat of a normal Road warrior configuration set up utilizing
Shorewall and OpenVPN.
The remote clients are not running shorewall, just a standard OpenVPN client.
The tun0 device on the shorewall server is configured like the following:
tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.99.1 P-t-P:172.16.99.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
I have a Linux VPN client that connects and gets assigned the IP address
172.16.99.10. I also have up/down scripts in place that update
/etc/resolv.conf so that its DNS server gets updated with the IP address
172.16.99.1.
Unfortunately a Shorewall:all2all:REJECT: message is logged when making
DNS queries.
The OpenVPN client can talk to the inside LAN which the shorewall server
is protecting, but it does not appear to be able to talk to the
172.16.99.0/24 leg which is the subnet of the tunnel.
I do have a a rule:
DNS/ACCEPT road fw
and a policy
ACCEPT fw road
Also the proper routes get pushed to the VPN client so that the protected
LAN subnet and the 172.16.99.0/24 sub-net go out the tun0 interface.
I have tried various configurations with the shorewall/masq,
shorewall/rfc1918, shorewall/tunnels file, but no combination appears to
allow me to query the DNS server that is running on the shorewall server.
The current entries look like the following:
shorewall/masq:
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
eth2 eth0
eth2 eth1
eth0 172.16.99.0/24
shorewall/rfc1918
#SUBNET TARGET
192.168.1.1 RETURN
172.16.99.0/24 RETURN # RFC 1918
192.168.168.0/24 logdrop # RFC 1918
10.0.0.0/24 logdrop # RFC 1918
shorewall/tunnels
#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver:1194 inet 0.0.0.0/0
Also note that the DNS server is listening on the 172.16.99.1 address.
I am hoping that someone knows what I am doing wrong based on the
information that has been provided. If a full shorewall report is needed,
please let me know and I can provide that information.
Thank You.
--
Scott
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Scott Ruckh wrote:> If a full shorewall report is needed, please let me knowA full report is needed if you would like me to look at your problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
This is what you said Tom Eastep> Scott Ruckh wrote: >> If a full shorewall report is needed, please let me know > > A full report is needed if you would like me to look at your problem. > > -Tom > --Ok, thanks. Attached is compressed output from a shorewall dump (unmodified). I believe the details from the original message explain the problem. A VPN client (openvpn), appears to have difficulty talking to devices on the openvpn subnet including DNS queries. Thank You. Scott ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Scott Ruckh wrote:> This is what you said Tom Eastep >> Scott Ruckh wrote: >>> If a full shorewall report is needed, please let me know >> A full report is needed if you would like me to look at your problem. >> >> -Tom >> -- > > Ok, thanks. Attached is compressed output from a shorewall dump > (unmodified). > > I believe the details from the original message explain the problem. A > VPN client (openvpn), appears to have difficulty talking to devices on the > openvpn subnet including DNS queries.You apparently don''t have LOGFILE set correctly to capture log messages in the dump output (it''s currently set to /var/log/messages). Please forward a copy of one of the ''all2all'' messages mentioned in your original post. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep wrote:> Scott Ruckh wrote: >> This is what you said Tom Eastep >>> Scott Ruckh wrote: >>>> If a full shorewall report is needed, please let me know >>> A full report is needed if you would like me to look at your problem. >>> >>> -Tom >>> -- >> Ok, thanks. Attached is compressed output from a shorewall dump >> (unmodified). >> >> I believe the details from the original message explain the problem. A >> VPN client (openvpn), appears to have difficulty talking to devices on the >> openvpn subnet including DNS queries. > > You apparently don''t have LOGFILE set correctly to capture log messages in > the dump output (it''s currently set to /var/log/messages). Please forward a > copy of one of the ''all2all'' messages mentioned in your original post.Also, this dump was captured when there was no VPN client even connected. So when we see the ''all2all'' message, we will still be guessing about what the actual IP configuration on your firewall is at the time of these failures. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
This is what you said Tom Eastep> Scott Ruckh wrote: >> This is what you said Tom Eastep >>> Scott Ruckh wrote: >>>> If a full shorewall report is needed, please let me know >>> A full report is needed if you would like me to look at your problem. >>> >>> -Tom >>> -- >> >> Ok, thanks. Attached is compressed output from a shorewall dump >> (unmodified). > > You apparently don''t have LOGFILE set correctly to capture log messages in > the dump output (it''s currently set to /var/log/messages). Please forward >Actually I do not have any logging in /var/log/messages either (possibly a misconfiguration). I am still using ULOGD and sending logs to MySQL database. I will send you link offline. Thanks. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
This is what you said Tom Eastep> Tom Eastep wrote: >> Scott Ruckh wrote: >>> This is what you said Tom Eastep >>>> Scott Ruckh wrote: >>>>> If a full shorewall report is needed, please let me know >>>> A full report is needed if you would like me to look at your problem. >>>> >>>> -Tom >>>> -- >>> Ok, thanks. Attached is compressed output from a shorewall dump >>> (unmodified). >>> >>> I believe the details from the original message explain the problem. A >>> VPN client (openvpn), appears to have difficulty talking to devices on >>> the >>> openvpn subnet including DNS queries. >> > Also, this dump was captured when there was no VPN client even connected. > So > when we see the ''all2all'' message, we will still be guessing about what > the > actual IP configuration on your firewall is at the time of these failures. >Attached is a new dump file while VPN client was connected. The VPN client attempted to resolve name from server connected to protected LAN and ping 172.16.99.1. Thank You. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Scott Ruckh wrote:> This is what you said Tom Eastep >> Tom Eastep wrote: >>> Scott Ruckh wrote: >>>> This is what you said Tom Eastep >>>>> Scott Ruckh wrote: >>>>>> If a full shorewall report is needed, please let me know >>>>> A full report is needed if you would like me to look at your problem. >>>>> >>>>> -Tom >>>>> -- >>>> Ok, thanks. Attached is compressed output from a shorewall dump >>>> (unmodified). >>>> >>>> I believe the details from the original message explain the problem. A >>>> VPN client (openvpn), appears to have difficulty talking to devices on >>>> the >>>> openvpn subnet including DNS queries. >> Also, this dump was captured when there was no VPN client even connected. >> So >> when we see the ''all2all'' message, we will still be guessing about what >> the >> actual IP configuration on your firewall is at the time of these failures. >> > Attached is a new dump file while VPN client was connected. The VPN > client attempted to resolve name from server connected to protected LAN > and ping 172.16.99.1.I don''t know why you are surpised about the pings -- you aren''t allowing ping from road->fw. And if I''m reading your log database correctly, you haven''t had a DNS packet logged from 172.16.99.10 since 6/23 but you had one accepted since the first dump according to the contents of the road2fw chain in the dump: Chain road2fw (1 references) pkts bytes target prot opt in out source destination 88 8018 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 1 67 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 The packet counter in the first dump was zero. Are you *sure* that you''re still having a DNS problem? -Tom PS -- and the last dump still doesn''t show any VPN client being connected - the only tun interface shown in the dump is tun0. -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
This is what you said Tom Eastep> Scott Ruckh wrote: >> This is what you said Tom Eastep >>> Tom Eastep wrote: >>>> Scott Ruckh wrote: >>>>> This is what you said Tom Eastep >>>>>> Scott Ruckh wrote: >>>>>>> If a full shorewall report is needed, please let me know >>>>>> A full report is needed if you would like me to look at your >>>>>> problem. >>>>>> >>>>>> -Tom >>>>>> -- >>>>> Ok, thanks. Attached is compressed output from a shorewall dump >>>>> (unmodified). >>>>> >>>>> I believe the details from the original message explain the problem. >>>>> A >>>>> VPN client (openvpn), appears to have difficulty talking to devices >>>>> on >>>>> the >>>>> openvpn subnet including DNS queries. >>> Also, this dump was captured when there was no VPN client even >>> connected. >>> So >>> when we see the ''all2all'' message, we will still be guessing about what >>> the >>> actual IP configuration on your firewall is at the time of these >>> failures. >>> >> Attached is a new dump file while VPN client was connected. The VPN >> client attempted to resolve name from server connected to protected LAN >> and ping 172.16.99.1. > > I don''t know why you are surpised about the pings -- you aren''t allowing > ping from road->fw.Yep, my mistake here. Shorewall just doing its job!!> And if I''m reading your log database correctly, you > haven''t had a DNS packet logged from 172.16.99.10 since 6/23 but you had > one > accepted since the first dump according to the contents of the road2fw > chainYeah I noticed the ACCEPTED DNS packet in the dump which I found odd because the DNS still returned no such host. Now that I see the ACCEPTED DNS packet from the shorewall dump I am beginning to question my DNS configuration. Possibly I have an ACL in place from that network???> The packet counter in the first dump was zero. > > Are you *sure* that you''re still having a DNS problem?I am definitely having a DNS problem. Whether it is a DNS problem because of shorewall is very questionable. You are correct that the DNS problem did not show up in the most current logs (from latest test) and logs only contain DNS entries from previous tests.> PS -- and the last dump still doesn''t show any VPN client being connected > the only tun interface shown in the dump is tun0.VPN client was definitely connected. I produced the dump file by SSH''ing to firewall while being connected via VPN. In the dump you can see the ACCEPT SSH in the road2fw section. This, I assume, was from my SSH session. Thanks. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Scott Ruckh wrote:> This is what you said Tom Eastep > > > Yeah I noticed the ACCEPTED DNS packet in the dump which I found odd > because the DNS still returned no such host. Now that I see the ACCEPTED > DNS packet from the shorewall dump I am beginning to question my DNS > configuration. Possibly I have an ACL in place from that network???Is your DNS server even bound to UDP port 53 on 172.16.99.1 (or 0.0.0.0)? Hint: netstat -unap | grep named> >> PS -- and the last dump still doesn''t show any VPN client being connected >> the only tun interface shown in the dump is tun0. > > VPN client was definitely connected. I produced the dump file by SSH''ing > to firewall while being connected via VPN. In the dump you can see the > ACCEPT SSH in the road2fw section. This, I assume, was from my SSH > session.You must be using an OpenVPN configuration scheme that I''m not familiar with then. On my routed configuration, each remote client that connects causes the creation of an additional tun device. That''s why the Shorewall OpenVPN documentation advocates defining the VPN zone using ''tun+'' (which you are doing). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
> > Are you *sure* that you''re still having a DNS problem? > > -TomLooks like I am just having unexpected behavior from the VPN client and the DNS query. This is from my DNS logs: 25-Jun-2007 13:39:24.039 info: client 172.16.99.10#32780: view standard-in: query: slug.domain.actdsltmp IN A + So it appears shorewall did what it was supposed to, BIND did what it was supposed to, but I did not get the desired response. Although VPN client''s /etc/resolv.conf has correct entries for "search" and "nameserver" (for the VPN network); DNS queries are not be returned as expected. In this instance, the VPN client queried for non-FQDM "slug", but from the above log the search domain is the one from the pre-vpn connection, and not from the post-vpn connection. Not sure why though??? It looks like I need to go back and write better up/down scripts for the OpenVPN client so that /etc/resolv.conf in configured in such a way that it will return expected results. I guess I needed a little hand holding to get me pointed in the right direction rather then staring around with a puzzled look not making any progress. Thanks. Scott ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/