Hello Lartc Mailing List:
Been working on something the last week and a half and ALMOST have it
working.., just need a few pointers from the wizards on this mailing list to
nail it.
Ok, my setup is a hub and spoke arrangement, hub is Cisco 2821 with IOS 12.4.
Spokes are ruggencom RX1000 routers, Debian based with the following versions
installed:
rx1000test:~# uname -a
Linux rx1000test 2.6.8-16-486-rx #1 Wed Mar 15 15:33:23 UTC 2006 i586
GNU/Linux
rx1000test:~# iptables -v
iptables v1.2.11: no command specified
rx1000test:~# shorewall version
2.2.3
rx1000test:~# ip -V
ip utility, iproute2-ss041019
rx1000test:~# ipsec version
Linux Openswan U2.2.0/K2.6.8-16-486-rx (native)
Openswan is using the Kernel 2.6 native stack NOT klips.
Here is my setup, only one spoke for now:
192.168.1.0/28 160.96.97.248 Dynamic
192.168.1.96/28
| 192.168.1.1 | | 192.168.1.97 |
| | HUB | | SPOKE | |
| | +------------+ | | +-----------+ | |
| | | | | | | | | |
+----------+ Cisco 2821 +--------INTERNET----------+ rx1000test+---------+
| | | | | |
| +------------+ +-----------+ |
| |
192.168.1.1(ipsec endpoint)----------------------(ipsec
endpoint)192.168.1.97
192.168.1.1(gre endpoint)-----------------(gre endpoint)192.168.1.97
192.168.2.110 gre tunnel 192.178.2.96/28 192.168.2.97
Here is the setup on te Cisco:
interface Tunnel6
ip address 192.168.2.110 255.255.255.240
tunnel source GigabitEthernet0/1
tunnel destination 192.168.1.97
exit
ip route 0.0.0.0 0.0.0.0 160.96.97.250
ip route 192.168.1.96 255.255.255.240 Tunnel6
ip route 192.168.1.97 255.255.255.255 GigabitEthernet0/0
! This last line is required to get around a recusive route error in the
cisco
Linux setup:
IPSec.conf
rx1000test:~# cat /etc/ipsec.conf
# /etc/ipsec.conf - Openswan IPsec configuration file
version 2.0 # conforms to second version of ipsec.conf specification
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
interfaces=%defaultroute
uniqueids=yes
# Add connections here
conn GDC1
authby=secret
auto=start
left=%defaultroute
leftsourceip=192.168.1.97
leftid=@rx1000test
leftsubnet=192.168.1.96/28
ike=aes128-md5-modp1024
esp=aes128-md5
right=160.96.97.248
rightsubnet=192.168.1.0/28
rightsourceip=192.168.1.1
type=tunnel
pfs=yes
keyingtries=0
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
The IPsec works fine except for the following caveats:
1. Spoke routers cannot ping each other,
2. The cisco has no interfaces for the scope routers so no qos can be done.
Linux GRE setup:
modprobe ip_gre
ip tunnel add GDC1 mode gre remote 192.168.1.1 local 192.168.1.97 ttl 255
ip link set GDC1 up
ip addr add 192.168.2.97/28 peer 192.168.2.110/28 dev GDC1
ip route del 192.168.1.0/28 via 160.96.97.248
ip route add 192.168.1.0/28 via 192.168.2.110
Ok, the ip route del was necessary to get rid of the IPSec route and replace
it
with the gre tunnel.
Linux box status:
rx1000test:~# ip addre 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 scope host lo
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:dc:04:7d:dc brd ff:ff:ff:ff:ff:ff
inet 192.168.1.97/28 brd 192.168.1.255 scope global eth1
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:0a:dc:04:7d:dd brd ff:ff:ff:ff:ff:ff
6: w1adsl: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:77:77:77:7b:b3 brd ff:ff:ff:ff:ff:ff
9: gre0: <NOARP> mtu 1428 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
12: GDC1@NONE: <POINTOPOINT,NOARP,PROMISC,UP> mtu 1514 qdisc noqueue
link/gre 192.168.1.97 peer 192.168.1.1
inet 192.168.2.97 peer 192.168.2.110/28 scope global GDC1
13: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1452 qdisc pfifo_fast qlen 3
link/ppp
inet 202.42.98.62 peer 202.42.98.1/32 scope global ppp1
rx1000test:~# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:dc:04:7d:dc brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:0a:dc:04:7d:dd brd ff:ff:ff:ff:ff:ff
6: w1adsl: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:77:77:77:7b:b3 brd ff:ff:ff:ff:ff:ff
9: gre0: <NOARP> mtu 1428 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
12: GDC1@NONE: <POINTOPOINT,NOARP,PROMISC,UP> mtu 1514 qdisc noqueue
link/gre 192.168.1.97 peer 192.168.1.1
13: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1452 qdisc pfifo_fast qlen 3
link/ppp
rx1000test:~# ip tun show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
GDC1: gre/ip remote 192.168.1.1 local 192.168.1.97 ttl 255
rx1000test:~# ip route show
202.42.98.1 dev ppp1 proto kernel scope link src 202.42.98.62
192.168.1.0/28 via 192.168.2.110 dev GDC1
192.168.2.96/28 dev GDC1 proto kernel scope link src 192.168.2.97
192.168.1.96/28 dev eth1 proto kernel scope link src 192.168.1.97
default dev ppp1 scope link
Now, here is my problem:
1. I can ping from the RX1000 ssh session into eth1(192.168.1.97) to all
interfaces and hosts on the network(pefect),
2. From the cisco ssh into Gig0/0(real ip interface) I can ping all tunnel
interfaces, all hosts on 192.168.1.0/28 but not 192.168.1.97(this makes
sense,
I'm outside the tunnel if ssh'd into the real IP interface),
3. All hosts on 192.168.1.0/28 can ping everything except addresses other
than
eth1 of RX1000 on 192.168.1.96/28. That is I get a ping response from
192.168.1.97 but not from any oterh hosts on that network. tcpdump -i GDC1
shows the ping coming from 192.168.1.7 to 192.168.1.101, but there is no
reply.
The ping and response from 192.168.1.7->192.168.1.97 is NOT going via GRE
according to the Cisco debug and tcpdump. Pings to 192.168.1.101 form
192.168.1.7 do go via the tunnel but are never answered. tcpdump -i eth1
indicate that the echo request from 192.168.1.7 uses the tunnel to get to
192.168.1.97 but never leaves the interface.
SO, number 3 is my big anomaly. The hosts that need access to the network,
192.168.1.96/28, don't have any and I can't figure out why.
Note that I am runnign shorewall, if I stop shorewall nothing changes. ALso,
have been watching /var/log/syslog with tail and there are no ping packets
being blocked by shorewall.
Does anybody have any ideas?
Cheers,
John
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
