Hello all,
I''m trying to host a Counter-Strike: Source server on my box, which has
two
interfaces, tun0 and eth0. (it''s running a VPN on tun0, with
connections
coming in on eth0).
The server is meant to listen on port 27015, tcp and udp protocols, on the
IP address 84.234.16.144. For the purposes of testing, I have been using
Netcat to listen on this port and IP, and Telnet to connect to this IP/port.
This is what I get from a filtered tcpdump:
Source | Destination | Protocol | Info
84.234.16.143 -> 84.234.16.144 TCP [SYN]
84.234.16.144 -> 84.234.16.143 TCP [SYN, ACK]
84.234.16.143 -> 84.234.16.144 TCP [ACK]
84.234.16.144 -> 84.234.16.143 TCP [FIN, ACK]
84.234.16.144 -> 84.234.16.143 TCP [RST, ACK]
84.234.16.143 -> 84.234.16.144 TCP [ACK]
84.234.16.144 -> 84.234.16.143 TCP [RST]
.143 is a client machine on tun0, .144 is one of the firewall machine''s
IPs.
The relevant rules in /rules are:
# accept half life 2 server sessions
ACCEPT:info all fw:84.234.16.144 all
ACCEPT:info fw:84.234.16.144 all all
I get the following showing up in my logs:
May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61103
DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61109
DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
... when trying to connect from the interface ''tun0''.
If anyone could shed some light onto this situation, I''d really
appreciate
it.
My full configuration is available here (sorry about the yousendit lameness,
the file''s 80kb):
http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3
Below is the information requested in the "Asking for Help" section of
the
Shorewall website.
Thanks,
Jan Mulders
0www~# /sbin/shorewall version
3.0.4
0www~#
0www~# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12
inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2
inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3
inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13
inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0
inet6 fe80::20a:e6ff:fea6:849b/64 scope link
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
100
link/[65534]
inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
0www~#
0www~# ip route show
84.234.16.145 dev tun0 scope link
84.234.16.145 dev eth0 scope link src 84.234.16.145
84.234.16.147 dev tun0 scope link
84.234.16.146 dev tun0 scope link
84.234.16.149 dev tun0 scope link
84.234.16.148 dev tun0 scope link
84.234.16.151 dev tun0 scope link
84.234.16.150 dev tun0 scope link
84.234.16.153 dev tun0 scope link
84.234.16.152 dev tun0 scope link
84.234.16.154 dev tun0 scope link
84.234.16.233 dev eth0 scope link
84.234.16.143 dev tun0 scope link
84.234.16.0/24 dev eth0 proto kernel scope link src 84.234.16.233
84.234.16.0/24 dev tun0 proto kernel scope link src 84.234.16.145
169.254.0.0/16 dev eth0 scope link
84.0.0.0/8 via 84.234.16.1 dev eth0
84.0.0.0/8 dev eth0 proto kernel scope link src 84.234.16.145
default via 84.234.16.1 dev eth0
0www~#
Hi Jan,
Not sure if maybe you should rather use bridge mode? We play a collection of
games over bridge mode, including CS:Source.
With the routing way, broadcasts are not transmitted over the tunnel, so
unless you can specify a server, I doubt if the clients will be able to
connect to it.
Hope it helps – happy huntin’
_____
From: shorewall-users-admin@lists.sourceforge.net
[mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Jan
Mulders
Sent: 17 May 2006 09:55 PM
To: shorewall-users@lists.sourceforge.net
Subject: [Shorewall-users] Shorewall and Counter-Strike: Source
Hello all,
I''m trying to host a Counter-Strike: Source server on my box, which has
two
interfaces, tun0 and eth0. (it''s running a VPN on tun0, with
connections
coming in on eth0).
The server is meant to listen on port 27015, tcp and udp protocols, on the
IP address HYPERLINK "http://84.234.16.144"84.234.16.144. For the
purposes
of testing, I have been using Netcat to listen on this port and IP, and
Telnet to connect to this IP/port.
This is what I get from a filtered tcpdump:
Source | Destination | Protocol | Info
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144 TCP [SYN]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143 TCP [SYN, ACK]
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144 TCP [ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143 TCP [FIN, ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143 TCP [RST, ACK]
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144 TCP [ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143 TCP [RST]
.143 is a client machine on tun0, .144 is one of the firewall machine''s
IPs.
The relevant rules in /rules are:
# accept half life 2 server sessions
ACCEPT:info all fw:HYPERLINK
"http://84.234.16.144"84.234.16.144 all
ACCEPT:info fw:HYPERLINK "http://84.234.16.144"84.234.16.144
all
all
I get the following showing up in my logs:
May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MACSRC=HYPERLINK "http://84.234.16.143"84.234.16.143 DST=HYPERLINK
"http://84.234.16.233"84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61103 DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MACSRC=HYPERLINK "http://84.234.16.143" 84.234.16.143 DST=HYPERLINK
"http://84.234.16.233"84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61109 DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
... when trying to connect from the interface ''tun0''.
If anyone could shed some light onto this situation, I''d really
appreciate
it.
My full configuration is available here (sorry about the yousendit lameness,
the file''s 80kb): HYPERLINK
"http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3
"http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3
Below is the information requested in the "Asking for Help" section of
the
Shorewall website.
Thanks,
Jan Mulders
0www~# /sbin/shorewall version
3.0.4
0www~#
0www~# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet HYPERLINK "http://127.0.0.1/8"127.0.0.1/8 brd HYPERLINK
"http://127.255.255.255"127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
inet HYPERLINK "http://84.234.16.233/24"84.234.16.233/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global eth0
inet HYPERLINK "http://84.234.16.145/8"84.234.16.145/8 brd
HYPERLINK
"http://84.255.255.255"84.255.255.255 scope global eth0:1
inet HYPERLINK "http://84.234.16.154/24"84.234.16.154/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:12
inet HYPERLINK "http://84.234.16.144/24"84.234.16.144/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:2
inet HYPERLINK "http://84.234.16.145/24"84.234.16.145/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:3
inet HYPERLINK "http://84.234.16.155/24"84.234.16.155/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:13
inet HYPERLINK "http://84.234.16.144/8"84.234.16.144/8 brd
HYPERLINK
"http://84.255.255.255"84.255.255.255 scope global secondary eth0:0
inet6 fe80::20a:e6ff:fea6:849b/64 scope link
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
100
link/[65534]
inet HYPERLINK "http://84.234.16.145/24"84.234.16.145/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global tun0
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit HYPERLINK "http://0.0.0.0"0.0.0.0 brd HYPERLINK
"http://0.0.0.0"0.0.0.0
0www~#
0www~# ip route show
HYPERLINK "http://84.234.16.145"84.234.16.145 dev tun0 scope link
HYPERLINK "http://84.234.16.145"84.234.16.145 dev eth0 scope link
src
HYPERLINK "http://84.234.16.145"84.234.16.145
HYPERLINK "http://84.234.16.147"84.234.16.147 dev tun0 scope link
HYPERLINK "http://84.234.16.146"84.234.16.146 dev tun0 scope link
HYPERLINK "http://84.234.16.149"84.234.16.149 dev tun0 scope link
HYPERLINK "http://84.234.16.148"84.234.16.148 dev tun0 scope link
HYPERLINK "http://84.234.16.151"84.234.16.151 dev tun0 scope link
HYPERLINK "http://84.234.16.150"84.234.16.150 dev tun0 scope link
HYPERLINK "http://84.234.16.153"84.234.16.153 dev tun0 scope link
HYPERLINK "http://84.234.16.152"84.234.16.152 dev tun0 scope link
HYPERLINK "http://84.234.16.154"84.234.16.154 dev tun0 scope link
HYPERLINK "http://84.234.16.233"84.234.16.233 dev eth0 scope link
HYPERLINK "http://84.234.16.143"84.234.16.143 dev tun0 scope link
HYPERLINK "http://84.234.16.0/24"84.234.16.0/24 dev eth0 proto kernel
scope link src HYPERLINK "http://84.234.16.233"84.234.16.233
HYPERLINK "http://84.234.16.0/24"84.234.16.0/24 dev tun0 proto kernel
scope link src HYPERLINK "http://84.234.16.145"84.234.16.145
HYPERLINK "http://169.254.0.0/16"169.254.0.0/16 dev eth0 scope link
HYPERLINK "http://84.0.0.0/8"84.0.0.0/8 via HYPERLINK
"http://84.234.16.1"84.234.16.1 dev eth0
HYPERLINK "http://84.0.0.0/8"84.0.0.0/8 dev eth0 proto kernel scope
link
src HYPERLINK "http://84.234.16.145"84.234.16.145
default via HYPERLINK "http://84.234.16.1"84.234.16.1 dev eth0
0www~#
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17
I''ve tested from both sides of the system (eth0 and tun0) - and I get the same result - the connection gets terminated by the server (presumably firewall) - which points to it not being a bridged vs routed issue. CS Source doesn''t use multicast either.. but thanks for the suggestion :) Regards, Jan Mulders On 18/05/06, Werner vd Merwe <werner@saicom.co.za> wrote:> > Hi Jan, > > > > Not sure if maybe you should rather use bridge mode? We play a collection > of games over bridge mode, including CS:Source. > > With the routing way, broadcasts are not transmitted over the tunnel, so > unless you can specify a server, I doubt if the clients will be able to > connect to it. > > > > Hope it helps – happy huntin'' > > > ------------------------------ > > *From:* shorewall-users-admin@lists.sourceforge.net [mailto: > shorewall-users-admin@lists.sourceforge.net] *On Behalf Of *Jan Mulders > *Sent:* 17 May 2006 09:55 PM > *To:* shorewall-users@lists.sourceforge.net > *Subject:* [Shorewall-users] Shorewall and Counter-Strike: Source > > > > Hello all, > > I''m trying to host a Counter-Strike: Source server on my box, which has > two interfaces, tun0 and eth0. (it''s running a VPN on tun0, with connections > coming in on eth0). > > The server is meant to listen on port 27015, tcp and udp protocols, on the > IP address 84.234.16.144. For the purposes of testing, I have been using > Netcat to listen on this port and IP, and Telnet to connect to this IP/port. > > This is what I get from a filtered tcpdump: > > Source | Destination | Protocol | Info > 84.234.16.143 -> 84.234.16.144 TCP [SYN] > 84.234.16.144 -> 84.234.16.143 TCP [SYN, ACK] > 84.234.16.143 -> 84.234.16.144 TCP [ACK] > 84.234.16.144 -> 84.234.16.143 TCP [FIN, ACK] > 84.234.16.144 -> 84.234.16.143 TCP [RST, ACK] > 84.234.16.143 -> 84.234.16.144 TCP [ACK] > 84.234.16.144 -> 84.234.16.143 TCP [RST] > > .143 is a client machine on tun0, .144 is one of the firewall machine''s > IPs. > > The relevant rules in /rules are: > > # accept half life 2 server sessions > ACCEPT:info all fw:84.234.16.144 all > ACCEPT:info fw:84.234.16.144 all all > > I get the following showing up in my logs: > > May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61103 > DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC=84.234.16.143DST> 84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61109 DF PROTO=TCP > SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > > ... when trying to connect from the interface ''tun0''. > > If anyone could shed some light onto this situation, I''d really appreciate > it. > > My full configuration is available here (sorry about the yousendit > lameness, the file''s 80kb): > http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3 > > Below is the information requested in the "Asking for Help" section of the > Shorewall website. > > Thanks, > > Jan Mulders > > > > > 0www~# /sbin/shorewall version > 3.0.4 > 0www~# > > 0www~# ip addr show > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff > inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0 > inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1 > inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12 > > inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2 > inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3 > inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13 > > inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0 > inet6 fe80::20a:e6ff:fea6:849b/64 scope link > valid_lft forever preferred_lft forever > 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen > 100 > link/[65534] > inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0 > 4: sit0: <NOARP> mtu 1480 qdisc noop > link/sit 0.0.0.0 brd 0.0.0.0 > 0www~# > > 0www~# ip route show > 84.234.16.145 dev tun0 scope link > 84.234.16.145 dev eth0 scope link src 84.234.16.145 > 84.234.16.147 dev tun0 scope link > 84.234.16.146 dev tun0 scope link > 84.234.16.149 dev tun0 scope link > 84.234.16.148 dev tun0 scope link > 84.234.16.151 dev tun0 scope link > 84.234.16.150 dev tun0 scope link > 84.234.16.153 dev tun0 scope link > 84.234.16.152 dev tun0 scope link > 84.234.16.154 dev tun0 scope link > 84.234.16.233 dev eth0 scope link > 84.234.16.143 dev tun0 scope link > 84.234.16.0/24 dev eth0 proto kernel scope link src 84.234.16.233 > 84.234.16.0/24 dev tun0 proto kernel scope link src 84.234.16.145 > 169.254.0.0/16 dev eth0 scope link > 84.0.0.0/8 via 84.234.16.1 dev eth0 > 84.0.0.0/8 dev eth0 proto kernel scope link src 84.234.16.145 > default via 84.234.16.1 dev eth0 > 0www~# > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17 > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17 >
Jan Mulders wrote:> > I get the following showing up in my logs: > > May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61103 > DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61109 > DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > > ... when trying to connect from the interface ''tun0''.So traffic from 84.234.16.233 enters tun0 destined for 84.234.16.233> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff > inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0Which happens to be the primary IP address of eth0.> inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1 > inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12 > inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2 > inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3 > inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13 > inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0 > inet6 fe80::20a:e6ff:fea6:849b/64 scope link > valid_lft forever preferred_lft forever > 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen > 100 > link/[65534] > inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0Strangely, tun0 is configured with the same network as eth0!> > 0www~# ip route show > 84.234.16.145 dev tun0 scope link > 84.234.16.145 dev eth0 scope link src 84.234.16.145 > 84.234.16.147 dev tun0 scope link > 84.234.16.146 dev tun0 scope link > 84.234.16.149 dev tun0 scope link > 84.234.16.148 dev tun0 scope link > 84.234.16.151 dev tun0 scope link > 84.234.16.150 dev tun0 scope link > 84.234.16.153 dev tun0 scope link > 84.234.16.152 dev tun0 scope link > 84.234.16.154 dev tun0 scope link > 84.234.16.233 dev eth0 scope link > 84.234.16.143 dev tun0 scope link > 84.234.16.0/24 dev eth0 proto kernel scope link src 84.234.16.233And the first route to 84.234.16.233 goes out of eth0. So when the firewall responds, the response is sent via eth0 rather than via tun0.> 84.234.16.0/24 dev tun0 proto kernel scope link src 84.234.16.145 > 169.254.0.0/16 dev eth0 scope link > 84.0.0.0/8 via 84.234.16.1 dev eth0 > 84.0.0.0/8 dev eth0 proto kernel scope link src 84.234.16.145 > default via 84.234.16.1 dev eth0 > 0www~# >Once again, it''s good to keep in mind that not all connection problems are Shorewall problems. This appears to be a case of a totally unworkable IP/VPN configuration. -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
I cut and pasted the wrong source IP address the first time -- what follows is hopefully correct: Jan Mulders wrote:>I get the following showing up in my logs: > >May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC>84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61103 >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 >May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC= SRC>84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61109 >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > >... when trying to connect from the interface ''tun0''. >So traffic from 84.234.16.143 enters tun0 destined for 84.234.16.233> >>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 >> link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff >> inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0 >Which happens to be the primary IP address of eth0.> >> inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1 >> inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12 >> inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2 >> inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3 >> inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13 >> inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0 >> inet6 fe80::20a:e6ff:fea6:849b/64 scope link >> valid_lft forever preferred_lft forever >>3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen >>100 >> link/[65534] >> inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0 >Strangely, tun0 is configured with the same network as eth0!> >>0www~# ip route show >>84.234.16.145 dev tun0 scope link >>84.234.16.145 dev eth0 scope link src 84.234.16.145 >>84.234.16.147 dev tun0 scope link >>84.234.16.146 dev tun0 scope link >>84.234.16.149 dev tun0 scope link >>84.234.16.148 dev tun0 scope link >>84.234.16.151 dev tun0 scope link >>84.234.16.150 dev tun0 scope link >>84.234.16.153 dev tun0 scope link >>84.234.16.152 dev tun0 scope link >>84.234.16.154 dev tun0 scope link >>84.234.16.233 dev eth0 scope link >>84.234.16.143 dev tun0 scope link >>84.234.16.0/24 dev eth0 proto kernel scope link src 84.234.16.233 >And the first route to 84.234.16.143 goes out of eth0. So when the firewall responds, the response is sent via eth0 rather than via tun0.>>84.234.16.0/24 dev tun0 proto kernel scope link src 84.234.16.145 >>169.254.0.0/16 dev eth0 scope link >>84.0.0.0/8 via 84.234.16.1 dev eth0 >>84.0.0.0/8 dev eth0 proto kernel scope link src 84.234.16.145 >>default via 84.234.16.1 dev eth0 >>0www~# >> >Once again, it''s good to keep in mind that not all connection problems are Shorewall problems. This appears to be a case of a totally unworkable IP/VPN/routing configuration. -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
Right. Do I ''just'' need to fix my routing to have a workable configuration, or do I need to rethink my entire setup? What would be a more correct/workable way of configuring this network? (see below) If nobody''s willing to explain to me how I should fix my routing setup (or rather, show me how it should''ve been designed in the first place), would anyone happen to have a link to where I should be reading up on network/routing design techniques? The original idea was to have .233 (the server''s main IP) seperate from the others, not involved in the vpn/routing at all, and to have .145 as the main IP used for the VPN/routing. See diagram below: Internet (eth0) ==== Webserver IP (.233) Internet (eth0) ==== VPN/Routing IP (.145) ==== Clients on VPN (tun0) ===Clients (.143 etc) The routing table on clients should be: -- specific routes for client''s proxy go here -- 0.0.0.0 84.234.16.145 0.0.0.0 UG 0 0 0 tun0 and my server should be: 84.234.16.143 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 84.234.16.147 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 0.0.0.0 84.234.16.1 0.0.0.0 UG 0 0 0 eth0 is this pretty much all I need for an example with two clients (.143 and .147)? Do I need to use the following to tell routing that some IPs are local, and if they come in on certain interfaces they need to be accepted? Do I add in routes for /sbin/route add -host 84.234.16.233 dev eth0 /sbin/route add -host 84.234.16.145 dev eth0:0 /sbin/route add -host 84.234.16.145 dev tun0 What is the order in which routing, iptables and my server''s daemons interact? Which comes first? Do I need different IPs for eth0 and tun0? Say, .233 for eth0, and .145 for tun0? What happens when a packet comes in destined for .233 on .145? Thanks for your assistance. I hope to understand this all by the time I''m done here :-) Regards, Jan Mulders On 18/05/06, Tom Eastep <teastep@shorewall.net> wrote:> > I cut and pasted the wrong source IP address the first time -- what > follows is hopefully correct: > > > Jan Mulders wrote: > > > >I get the following showing up in my logs: > > > >May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC> SRC> >84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 > ID=61103 > >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > >May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC> SRC> >84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 > ID=61109 > >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0 > > > >... when trying to connect from the interface ''tun0''. > > > > So traffic from 84.234.16.143 enters tun0 destined for 84.234.16.233 > > > > >>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > >> link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff > >> inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0 > > > > Which happens to be the primary IP address of eth0. > > > > >> inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1 > >> inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary > eth0:12 > >> inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2 > >> inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3 > >> inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary > eth0:13 > >> inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0 > >> inet6 fe80::20a:e6ff:fea6:849b/64 scope link > >> valid_lft forever preferred_lft forever > >>3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen > >>100 > >> link/[65534] > >> inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0 > > > > Strangely, tun0 is configured with the same network as eth0! > > > > >>0www~# ip route show > >>84.234.16.145 dev tun0 scope link > >>84.234.16.145 dev eth0 scope link src 84.234.16.145 > >>84.234.16.147 dev tun0 scope link > >>84.234.16.146 dev tun0 scope link > >>84.234.16.149 dev tun0 scope link > >>84.234.16.148 dev tun0 scope link > >>84.234.16.151 dev tun0 scope link > >>84.234.16.150 dev tun0 scope link > >>84.234.16.153 dev tun0 scope link > >>84.234.16.152 dev tun0 scope link > >>84.234.16.154 dev tun0 scope link > >>84.234.16.233 dev eth0 scope link > >>84.234.16.143 dev tun0 scope link > >>84.234.16.0/24 dev eth0 proto kernel scope link src 84.234.16.233 > > > > And the first route to 84.234.16.143 goes out of eth0. So when the > firewall responds, the response is sent via eth0 rather than via tun0. > > > >>84.234.16.0/24 dev tun0 proto kernel scope link src 84.234.16.145 > >>169.254.0.0/16 dev eth0 scope link > >>84.0.0.0/8 via 84.234.16.1 dev eth0 > >>84.0.0.0/8 dev eth0 proto kernel scope link src 84.234.16.145 > >>default via 84.234.16.1 dev eth0 > >>0www~# > >> > > > > Once again, it''s good to keep in mind that not all connection problems > are Shorewall problems. This appears to be a case of a totally > unworkable IP/VPN/routing configuration. > > -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 > > >
Hi Jan I don''t really understand why you want your clients to be on VPN. Why not a direct connection? If the point is to keep uninvited players from joining, then isn''t there a simpler way to do that? How about running the server on an unusual port, and only telling the people you want to join? If you are looking for stuff to read, there seems to be plenty on www.openvpn.org. Really, your problem seems more to be the proper setup of VPN, rather than Shorewall. Additionally, Tom has written a guide: http://www.shorewall.net/OPENVPN.html . If I guess your intentions correctly, your setup should look like his road-warrior description. Another thing: you seem to be using a lot of 84.234.16.xxx addresses. These are public IP addresses, and you should only use them if they have been allocated to you. If you need private IP addresses, you should use one of the ranges reserved for that, such as 10.xxx.xxx.xxx. Rune ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
RK> I don''t really understand why you want your clients to be on VPN. Why RK> not a direct connection? Or is it that CS: Source can only be played on LANs. Then you should pay attention to Werner''s post: WM>Not sure if maybe you should rather use bridge mode? WM>We play a collection of games over bridge mode, including CS:Source. WM> WM>With the routing way, broadcasts are not transmitted WM>over the tunnel, so unless you can specify a server, WM>I doubt if the clients will be able to connect to it. RK> If you are looking for stuff to read, there seems to be plenty on RK> www.openvpn.org. Sorry, that is www.openvpn.net There is a special guide to ethernet bridging. Rune ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
No no, the CS server is in addition to the VPN... I am running the VPN so paying clients can utilise a full, routed Internet connection, with their own public IP address, and also connect to my CS server if they wish. Sort of a "value-added" package if you get what I mean? Basically, it boils down to exactly the same as a standard proxyarp''ed client network - I have a LAN with a couple client machines on one side (tun0), and the Internet on the other (eth0). I also happrn to want to run a games server so both can access it. Clients get full public IPs, so they can host servers of their own and Internet users can connect, but by moving the server down one hop (and away from the HTTPS proxys clients are using to connect), they lose about 20ms of latency. No different from running a standard TCP service on the server. Hope this clears things up. Thanks, Jan On 19/05/06, Rune Kock <rune.kock@gmail.com> wrote:> > RK> I don''t really understand why you want your clients to be on VPN. Why > RK> not a direct connection? > > Or is it that CS: Source can only be played on LANs. Then you should > pay attention to Werner''s post: > > WM>Not sure if maybe you should rather use bridge mode? > WM>We play a collection of games over bridge mode, including CS:Source. > WM> > WM>With the routing way, broadcasts are not transmitted > WM>over the tunnel, so unless you can specify a server, > WM>I doubt if the clients will be able to connect to it. > > RK> If you are looking for stuff to read, there seems to be plenty on > RK> www.openvpn.org. > > Sorry, that is www.openvpn.net > > There is a special guide to ethernet bridging. > > > Rune > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >
> No no, the CS server is in addition to the VPN... I am running the VPN so > paying clients can utilise a full, routed Internet connection, with their > own public IP address, and also connect to my CS server if they wish. Sort > of a "value-added" package if you get what I mean?Oh, then I''m sorry for making lame comments in my earlier post. I don''t think that I know enough about routing to help you with this. Rune ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642