by I have a problem with vpnd, and traffic is rather low on the list, so...
A testsetup works perfectly, but in a real world setup I can't get
trafic through.
Testsetup:
cisco -- firewall-vpn-gw -- internal nets: 10.{2. 3. 10. 11. 12. 13.}
10.0.0.1 10.0.0.2 |
10.1.0.1 -- clientnet-vpn-gw ----- testclient
10.1.0.2 10.15.0.1 10.15.0.5
Partial firewall-vpn-gw server setup:
mode server
server 10.0.0.2 19800
client 10.1.0.2 19800
local 10.0.0.2
remote 10.15.0.1
autoroute
Partial clientnet-vpn-gw vpnd.conf:
mode client
server 10.0.0.2 19800
client 10.1.0.2 19800
local 10.15.0.1
remote 10.0.0.2
autoroute
The server/client interfaces are used for the initial connection and
negotiation. After that the slip links (sl0) are used for the encrypted
tunnel between local/remote.
Vpnd itself creates these sl0's on each vpn-gw.
I have ipchains rules working for all 'normal' inet traffic, i.e., the
nessesary icmp is allowed everywhere, almost any outgoing allowed, and
ingoing tcp/udp is allowed as is nessesary.
I have bidirektional tcp rules for vpn tcp trafik between the two vpn
interfaces on port 19800 (arbitrary chosen), i.e.between 10.1.0.1 and
10.0.0.2 .
Real world setup:
200.300.400.501
nat -> 10.0.0.2
+-- cisco -- firewall-vpn-gw --- clientnets: 10.{10. 11. 12. 13.}
| 10.0.0.1 10.0.0.2 --- servernet : gw:10.1.0.1
|
+---------- clientnet-vpn-gw ----- testclient
20.30.40.51 10.15.0.1 10.15.0.5
Here I can traceroute to 10.0.0.2, but not further to the internal net.
If I change the config so that the firewall-vpn-gw 'local' is 10.1.0.1,
and
clientnet-vpn-gw 'remote' is 10.1.0.1, I can traceroute to 10.1.0.1, but
not further.
Firewall rules are unchanged, except that IP#'s are changed, of cause.Quote:>From this, I deduce it's a routing problem.
Partial firewall-vpn-gw server setup:
mode server
server 200.300.400.500 19900
client 20.30.40.50 19800
local 10.0.0.2
remote 10.15.0.1
autoroute
Partial clientnet-vpn-gw vpnd.conf:
mode client
server 200.300.400.500 19800
client 20.30.40.50 19800
local 10.15.0.1
remote 10.0.0.2
autoroute
Firewall-vpn-gw 'route -n':
Destination Gateway Genmask Flags Metric Ref Use Iface
10.2.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
10.10.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth4
10.3.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth3
10.11.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth5
10.1.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.15.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 sl0
10.12.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth6
10.13.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth7
10.2.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2
10.3.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth4
10.11.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth5
10.12.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth6
10.13.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth7
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
Client-vpn-gw 'route -n':
Destination Gateway Genmask Flags Metric Ref Use Iface
20.30.40.51 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 sl0
10.15.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
20.30.40.50 0.0.0.0 255.255.255.240 U 0 0 0 eth0
10.15.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 20.30.40.51 0.0.0.0 UG 0 0 0 eth0
As can be seen from the two routing tables, a slip (sl0) route exists
from Firewall-vpn-gw to Client-vpn-gw:
10.15.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 sl0
and visaversa from Client-vpn-gw to Firewall-vpn-gw:
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 sl0
Normally, a Linux kernen will create routes by itself, and routes do
exist between all internal interfaces.
One thing I haven't thought of until now is masquarading.
In the firewall on each gateway, I masquerade all internal interfaces,
i.e. on Firewall-vpn-gw it is eth{1,2,3,4,5,6,7}, on Client-vpn-gw it is
eth1.
In the testsetup, the vpn connection is placed on one of the internal
interfaces, which has already been masqueraded, while in the 'real
world' setup, sl0 is not included in the masquerading.
So, maybe all I need is to add sl0 to the masquerading?
--
Regards,
Mr Dev - Mogens Valentin
OpenSource Security - Networking - Programming
S?ger 2-3 v?r. lejlighed, helst fra 1. marts
Istands?ttelse i noget omfang kan tilbydes