Hi All:
Ok, here is my setup:
Linux Side 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
dpddelay=30
dpdtimeout=90
dpdaction=clear
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
With no GRE, this works fine with the Cisco.
Here are the Tunnel configs:
Linux SIde:
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 dev GDC1
Note: I''ve not yet added route, I want to get the
tunnel up and pinging first.
Cisco interface Tunnel6
ip address 192.168.2.110 255.255.255.240
tunnel source GigabitEthernet0/1
tunnel destination 192.168.1.97
Ok, now I have debug tunnels on on the cisco, and on
the linux tcpdump -i ppp1 not tcp port 22.
WHen I ping from the Linux to the Cisco here is what I
get:
rx1000test:~# ping 192.168.2.110 -w 4
PING 192.168.2.110 (192.168.2.110) 56(84) bytes of
data.
--- 192.168.2.110 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss,
time 3001ms
TCPDUMP:
01:21:19.845754 IP adsl1500-17.dyn98.pacific.net.sg >
192.168.2.110: icmp 64: echo request seq 1
01:21:20.847192 IP adsl1500-17.dyn98.pacific.net.sg >
192.168.2.110: icmp 64: echo request seq 2
01:21:21.847040 IP adsl1500-17.dyn98.pacific.net.sg >
192.168.2.110: icmp 64: echo request seq 3
01:21:22.846938 IP adsl1500-17.dyn98.pacific.net.sg >
192.168.2.110: icmp 64: echo request seq 4
Cisco Debug OUtput:
None, nothing showed up.
Now, when I ping from the cisco to the Linux:
SirentRouter#ping 192.168.2.97
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.97,
timeout is 2 seconds:
*Jul 16 17:31:00.968: Tunnel6: GRE/IP encapsulated
192.168.1.1->192.168.1.97 (linktype=7, len=124).
*Jul 16 17:31:02.968: Tunnel6: GRE/IP encapsulated
192.168.1.1->192.168.1.97 (linktype=7, len=124).
*Jul 16 17:31:04.968: Tunnel6: GRE/IP encapsulated
192.168.1.1->192.168.1.97 (linktype=7, len=124).
*Jul 16 17:31:06.968: Tunnel6: GRE/IP encapsulated
192.168.1.1->192.168.1.97 (linktype=7, len=124).
*Jul 16 17:31:08.968: Tunnel6: GRE/IP encapsulated
192.168.1.1->192.168.1.97 (linktype=7, len=124).
Success rate is 0 percent (0/5)
TCPDUMP:
01:23:12.355291 IP 160.96.97.248 >
adsl1500-17.dyn98.pacific.net.sg:
ESP(spi=0x5729d338,seq=0x50)
01:23:12.355291 IP 192.168.1.1 > 192.168.1.97: IP
192.168.2.110 > 192.168.2.97: icmp 80: echo request
seq 1
01:23:12.356942 IP 192.168.2.97 > 192.168.2.110: icmp
80: echo reply seq 1
01:23:14.357966 IP 160.96.97.248 >
adsl1500-17.dyn98.pacific.net.sg:
ESP(spi=0x5729d338,seq=0x51)
01:23:14.357966 IP 192.168.1.1 > 192.168.1.97: IP
192.168.2.110 > 192.168.2.97: icmp 80: echo request
seq 2
01:23:14.359619 IP 192.168.2.97 > 192.168.2.110: icmp
80: echo reply seq 2
01:23:16.273299 IP
adsl1500-17.dyn98.pacific.net.sg.isakmp >
160.96.97.248.isakmp: isakmp: phase 2/others ? inf[E]
01:23:16.290605 IP 160.96.97.248.isakmp >
adsl1500-17.dyn98.pacific.net.sg.isakmp: isakmp: phase
2/others ? inf[E]
01:23:16.355673 IP 160.96.97.248 >
adsl1500-17.dyn98.pacific.net.sg:
ESP(spi=0x5729d338,seq=0x52)
01:23:16.355673 IP 192.168.1.1 > 192.168.1.97: IP
192.168.2.110 > 192.168.2.97: icmp 80: echo request
seq 3
01:23:16.357130 IP 192.168.2.97 > 192.168.2.110: icmp
80: echo reply seq 3
01:23:18.358878 IP 160.96.97.248 >
adsl1500-17.dyn98.pacific.net.sg:
ESP(spi=0x5729d338,seq=0x53)
01:23:18.358878 IP 192.168.1.1 > 192.168.1.97: IP
192.168.2.110 > 192.168.2.97: icmp 80: echo request
seq 4
01:23:18.360337 IP 192.168.2.97 > 192.168.2.110: icmp
80: echo reply seq 4
It looks almost perfect. I get an encrypted GRE ping
from the cisco side, Linux receives the echo request
and responds but it does not appear to be getting
encrypted. And that I think is the problem.
Shorewall is not involved, there is nothing that
showed up in the syslog during the tests, I think I
have that all sorted.
Anyone have any ideas on how to fix this?
Cheers,
John
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
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
On Sun, 2006-07-16 at 10:31 -0700, John Serink wrote:> Note: I''ve not yet added route, I want to get the > tunnel up and pinging first.I suspect that you need a route to 192.168.1.1 via GDC1. -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 ------------------------------------------------------------------------- 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
Hi Tom: First, thank you for the help thus far. Ok, I know that I will need a route to 192.168.1.0\28 eventually, but my problem is I can''t ping the opposite ends of the thunnel from each side. The pings from the Cisco are getting to the Linux box as shown in the tcpdump...the linux box then responds but it deems the Linux reponses are NOT getting encrypted by Openswan ans there is no ESP packet leaving ppp1. When the pings arrive from the cisco, first an ESP packet arrives and then the decoded icmp is there...at least that''s what it looks like to me. I''ll have to check my shorewall setup, especially the shorewall.conf to make sure I''m writing everything to the log as presently, nothing is showing up in syslog to give me a clue. cheers, john --- Tom Eastep <teastep@shorewall.net> wrote:> On Sun, 2006-07-16 at 10:31 -0700, John Serink > wrote: > > > Note: I''ve not yet added route, I want to get the > > tunnel up and pinging first. > > I suspect that you need a route to 192.168.1.1 via > GDC1. > > -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 > > >-------------------------------------------------------------------------> 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> > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users>__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- 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
On Sun, 2006-07-16 at 18:34 -0700, John Serink wrote:> I''ll have to check my shorewall setup, especially the > shorewall.conf to make sure I''m writing everything to > the log as presently, nothing is showing up in syslog > to give me a clue.If you "shorewall clear", does it work? If not, then please take this thread off of the Shorewall list because your problem has nothing to do with Shorewall. -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 ------------------------------------------------------------------------- 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
Hi Tom: Ok, I have found one of my problems.... When I setup the tunnel with the following: 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 brd + dev GDC1 ip route del 192.168.1.0/28 ip route add 192.168.1.0/28 dev GDC1 It doesn''t work...UNTIL, I do this: shorewall restart I have a dynamic IP so the IP ''may'' roll over at any time. With this in mind, a couple of questions: 1. Is ther a reasons that shorewall with a GRE tunnel running over IPSec needs to be restarted when the tunnel is loaded? 2. Is there anyway to speed up the restart of shorewall? I have tried a shorewall refresh but that did not work, I had to issue a restart. Cheers, John --- Tom Eastep <teastep@shorewall.net> wrote:> On Sun, 2006-07-16 at 18:34 -0700, John Serink wrote: > > > I''ll have to check my shorewall setup, especially the > > shorewall.conf to make sure I''m writing everything to > > the log as presently, nothing is showing up in syslog > > to give me a clue. > > If you "shorewall clear", does it work? If not, then please take this > thread off of the Shorewall list because your problem has nothing to do > with Shorewall. > > -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 > > > ------------------------------------------------------------------------- > 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 > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> > > I have a dynamic IP so the IP ''may'' roll over at any time. With this in mind, a > couple of questions: > 1. Is ther a reasons that shorewall with a GRE tunnel running over IPSec needs > to be restarted when the tunnel is loaded?None that I can think of. What entries in your Shorewall config files do you have that mention GDC1? If you "shorewall dump > dump1.txt" before the restart of Shorewall then "shorewall dump > dump2.txt" afterwards, what differences do you see in the two dumps (other than packet and byte counts).> 2. Is there anyway to speed up the restart of shorewall?That is Shorewall FAQ 34.> > I have tried a shorewall refresh but that did not work, I had to issue a > restart. >If you read the documentation for "shorewall refresh", you will see that those results are unsurprising. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom:
Ok, shorewall dump doesn''t appear to work on shorewall 2.2.3.
GDC1 is not entioned in any of my shorewall config files, its the name of the
Tunnel:
rx1000test:~# ip addr
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
8: gre0: <NOARP> mtu 1476 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
12: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1452 qdisc pfifo_fast qlen
3
link/ppp
inet 202.42.98.94 peer 202.42.98.1/32 scope global ppp1
13: GDC1@NONE: <POINTOPOINT,NOARP,PROMISC,UP> mtu 1428 qdisc noqueue
link/gre 192.168.1.97 peer 192.168.1.1
inet 192.168.2.97/28 brd 192.168.2.111 scope global GDC1
Its at the bottom...
rx1000test:~# ip tun
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
Any ideas and why shorewall needs to be restarted?
The shorewall -f start is MAGIC! Thankyou.
Cheers,
John
--- Tom Eastep <teastep@shorewall.net> wrote:
> John Serink wrote:
> >
> >
> > I have a dynamic IP so the IP ''may'' roll over at any
time. With this in
> mind, a
> > couple of questions:
> > 1. Is ther a reasons that shorewall with a GRE tunnel running over
IPSec
> needs
> > to be restarted when the tunnel is loaded?
>
> None that I can think of. What entries in your Shorewall config files do
you
> have that mention GDC1? If you "shorewall dump > dump1.txt"
before the
> restart
> of Shorewall then "shorewall dump > dump2.txt" afterwards,
what differences
> do
> you see in the two dumps (other than packet and byte counts).
>
> > 2. Is there anyway to speed up the restart of shorewall?
>
> That is Shorewall FAQ 34.
>
> >
> > I have tried a shorewall refresh but that did not work, I had to issue
a
> > restart.
> >
>
> If you read the documentation for "shorewall refresh", you will
see that
> those
> results are unsurprising.
>
> -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
>
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> Hi Tom: > > Ok, shorewall dump doesn''t appear to work on shorewall 2.2.3.Ok -- if you are running that ancient a version of Shorewall then all bets are off (yes, I know that museum pieces like Debian stable still include it). I don''t support anything older than 2.4 (and that will only be supported for another couple of weeks). The problem is that I don''t remember accurately how those old versions worked and it takes too much of my time when I have to read the old code in order to refresh my memory.> > GDC1 is not entioned in any of my shorewall config files, its the name of the > Tunnel:Then I''m amazed that it works at all. Is any traffic actually going through the tunnel? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom:> Ok -- if you are running that ancient a version of Shorewall then all bets > are > off (yes, I know that museum pieces like Debian stable still include it). I > don''t support anything older than 2.4 (and that will only be supported for > another couple of weeks). The problem is that I don''t remember accurately how > those old versions worked and it takes too much of my time when I have to > read > the old code in order to refresh my memory.Understand. Yah, running Debian.> > > > > GDC1 is not entioned in any of my shorewall config files, its the name of > the > > Tunnel: > > Then I''m amazed that it works at all. Is any traffic actually going through > the > tunnel?Sure! Everthing works fromthe router, but hosts behind it don''t. I should use the name of the tunnel in the shorewall config files for the tunnel zone? Cheers, John> > -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 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>_______________________________________________> Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> > Sure! Everthing works fromthe router, but hosts behind it don''t. > I should use the name of the tunnel in the shorewall config files for the > tunnel zone? >Please check out http://www.shorewall.net/IPIP.htm -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Oops...I lied, my interfaces file: #ZONE INTERFACE BROADCAST OPTIONS tun GDC1 net ppp1 - blacklist,nosmurfs,tcpflags loc eth1 192.168.1.111/28 --- Tom Eastep <teastep@shorewall.net> wrote:> John Serink wrote: > > > > Sure! Everthing works fromthe router, but hosts behind it don''t. > > I should use the name of the tunnel in the shorewall config files for the > > tunnel zone? > > > > Please check out http://www.shorewall.net/IPIP.htm > > -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 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>_______________________________________________> Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> Oops...I lied, my interfaces file: > #ZONE INTERFACE BROADCAST OPTIONS > tun GDC1 > net ppp1 - blacklist,nosmurfs,tcpflags > loc eth1 192.168.1.111/28 >Nothing there that requires a restart. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> > Ok, shorewall dump doesn''t appear to work on shorewall 2.2.3. >On 2.2.3, "shorewall status" did something similar. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Ok, here it is: rx1000test:~# diff b4restart.txt afterrestart.txt 1c1 < Shorewall-2.2.3 Status at rx1000test - Sun Jul 23 02:15:04 SGT 2006 ---> Shorewall-2.2.3 Status at rx1000test - Sun Jul 23 02:16:37 SGT 20063c3 < Counters reset Sun Jul 23 00:04:58 SGT 2006 ---> Counters reset Sun Jul 23 02:16:14 SGT 20068,10c8,10 < 49 4116 GDC1_in all -- GDC1 * 0.0.0.0/0 0.0.0.0/0 < 590 83026 ppp1_in all -- ppp1 * 0.0.0.0/0 0.0.0.0/0 < 1908 119K eth1_in all -- eth1 * 0.0.0.0/0 0.0.0.0/0 ---> 3 252 GDC1_in all -- GDC1 * 0.0.0.0/0 0.0.0.0/0 > 6 828 ppp1_in all -- ppp1 * 0.0.0.0/0 0.0.0.0/0 > 81 5372 eth1_in all -- eth1 * 0.0.0.0/0 0.0.0.0/018,19c18,19 < 69331 30M ppp1_fwd all -- ppp1 * 0.0.0.0/0 0.0.0.0/0 < 39178 3628K eth1_fwd all -- eth1 * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ppp1_fwd all -- ppp1 * 0.0.0.0/0 0.0.0.0/0 > 0 0 eth1_fwd all -- eth1 * 0.0.0.0/0 0.0.0.0/024c24 < Chain OUTPUT (policy DROP 0 packets, 0 bytes) ---> Chain OUTPUT (policy DROP 1 packets, 108 bytes)28,31c28,31 < 109 9156 fw2tun all -- * GDC1 0.0.0.0/0 0.0.0.0/0 < 140 14376 fw2vpn all -- * ppp1 0.0.0.0/0 192.168.1.0/28 < 56 6330 fw2net all -- * ppp1 0.0.0.0/0 0.0.0.0/0 < 2143 262K fw2loc all -- * eth1 0.0.0.0/0 0.0.0.0/0 ---> 3 252 fw2tun all -- * GDC1 0.0.0.0/0 0.0.0.0/0 > 3 324 fw2vpn all -- * ppp1 0.0.0.0/0192.168.1.0/28> 0 0 fw2net all -- * ppp1 0.0.0.0/0 0.0.0.0/0 > 56 5948 fw2loc all -- * eth1 0.0.0.0/0 0.0.0.0/043,50c43,50 < 361 53064 RejectAuth all -- * * 0.0.0.0/0 0.0.0.0/0 < 361 53064 dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 < 3 360 AllowICMPs icmp -- * * 0.0.0.0/0 0.0.0.0/0 < 361 53064 dropInvalid all -- * * 0.0.0.0/0 0.0.0.0/0 < 360 52888 DropSMB all -- * * 0.0.0.0/0 0.0.0.0/0 < 350 52408 DropUPnP all -- * * 0.0.0.0/0 0.0.0.0/0 < 20 880 dropNotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 < 333 51664 DropDNSrep all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 RejectAuth all -- * * 0.0.0.0/00.0.0.0/0> 0 0 dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 AllowICMPs icmp -- * * 0.0.0.0/00.0.0.0/0> 0 0 dropInvalid all -- * * 0.0.0.0/00.0.0.0/0> 0 0 DropSMB all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 DropUPnP all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 dropNotSyn tcp -- * * 0.0.0.0/00.0.0.0/0> 0 0 DropDNSrep all -- * * 0.0.0.0/00.0.0.0/0 62,63c62,63 < 2 96 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 < 8 384 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445 ---> 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp dpt:139> 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp dpt:445 79,80c79,80 < 49 4116 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 < 49 4116 tun2fw all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 3 252 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 > 3 252 tun2fw all -- * * 0.0.0.0/0 0.0.0.0/0127c127 < 1 176 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID ---> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0state INVALID 131c131 < 17 744 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x16/0x02 ---> 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp flags:!0x16/0x02 138c138 < 39178 3628K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0141,142c141,142 < 14 840 loc2vpn all -- * ppp1 0.0.0.0/0 192.168.1.0/28 < 39164 3627K loc2net all -- * ppp1 0.0.0.0/0 0.0.0.0/0 ---> 0 0 loc2vpn all -- * ppp1 0.0.0.0/0192.168.1.0/28> 0 0 loc2net all -- * ppp1 0.0.0.0/0 0.0.0.0/0146,147c146,147 < 1908 119K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 < 1908 119K loc2fw all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 81 5372 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 > 81 5372 loc2fw all -- * * 0.0.0.0/0 0.0.0.0/0151,152c151,152 < 2140 262K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED < 3 372 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 56 5948 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0158c158 < 33 4021 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED 161c161 < 4 664 ACCEPT udp -- * * 0.0.0.0/0 160.96.97.248 udp dpt:500 state NEW ---> 0 0 ACCEPT udp -- * * 0.0.0.0/0160.96.97.248 udp dpt:500 state NEW 164c164 < 19 1645 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0168,169c168,169 < 6 504 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED < 103 8652 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED> 3 252 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0173,175c173,175 < 108 11664 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED < 1 108 ACCEPT 47 -- * * 0.0.0.0/0 192.168.1.1 < 31 2604 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 3 324 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED> 0 0 ACCEPT 47 -- * * 0.0.0.0/0192.168.1.1> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0182c182 < 1899 119K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ---> 81 5372 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED 184c184 < 9 702 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0191c191 < 37519 3537K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED 193c193 < 49 3425 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ---> 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0udp dpt:53 197c197 < 1596 86364 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0208c208 < 14 840 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0219,221c219,221 < 361 53064 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 < 333 51664 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:net2all:DROP:'' < 333 51664 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0LOG flags 0 level 6 prefix `Shorewall:net2all:DROP:''> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0225,226c225,226 < 39 4778 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED < 97 15640 ACCEPT esp -- * * 160.96.97.248 0.0.0.0/0 ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED> 3 504 ACCEPT esp -- * * 160.96.97.248 0.0.0.0/0228c228 < 3 808 ACCEPT udp -- * * 160.96.97.248 0.0.0.0/0 udp dpt:500 state NEW ---> 0 0 ACCEPT udp -- * * 160.96.97.248 0.0.0.0/0udp dpt:500 state NEW 233c233 < 361 53064 net2all all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 net2all all -- * * 0.0.0.0/0 0.0.0.0/0237c237 < 69331 30M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ---> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED 245,246c245,246 < 69331 30M dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 < 69331 30M blacklst all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 blacklst all -- * * 0.0.0.0/0 0.0.0.0/0248c248 < 68954 30M tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0260c260 < 69331 30M net2loc all -- * eth1 0.0.0.0/0 0.0.0.0/0 ---> 0 0 net2loc all -- * eth1 0.0.0.0/0 0.0.0.0/0264,267c264,267 < 590 83026 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 < 590 83026 blacklst all -- * * 0.0.0.0/0 0.0.0.0/0 < 468 70100 smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW < 43 2549 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0 ---> 6 828 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 > 6 828 blacklst all -- * * 0.0.0.0/0 0.0.0.0/0 > 3 504 smurfs all -- * * 0.0.0.0/0 0.0.0.0/0state INVALID,NEW> 0 0 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0269,270c269,270 < 90 8736 vpn2fw all -- * * 192.168.1.0/28 0.0.0.0/0 < 500 74290 net2fw all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 3 324 vpn2fw all -- * * 192.168.1.0/28 0.0.0.0/0 > 3 504 net2fw all -- * * 0.0.0.0/0 0.0.0.0/0306c306 < 49 4116 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ---> 3 252 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED 317,318c317,318 < 83 8148 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED < 7 588 ACCEPT 47 -- * * 192.168.1.1 0.0.0.0/0 ---> 3 324 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0state RELATED,ESTABLISHED> 0 0 ACCEPT 47 -- * * 192.168.1.1 0.0.0.0/0330c330 < Chain PREROUTING (policy ACCEPT 1892 packets, 132K bytes) ---> Chain PREROUTING (policy ACCEPT 1893 packets, 133K bytes)333c333 < Chain POSTROUTING (policy ACCEPT 101 packets, 11149 bytes) ---> Chain POSTROUTING (policy ACCEPT 105 packets, 11497 bytes)335c335 < 1550 83080 ppp1_masq all -- * ppp1 0.0.0.0/0 0.0.0.0/0 ---> 0 0 ppp1_masq all -- * ppp1 0.0.0.0/0 0.0.0.0/0337c337 < Chain OUTPUT (policy ACCEPT 85 packets, 7437 bytes) ---> Chain OUTPUT (policy ACCEPT 88 packets, 7689 bytes)343c343 < 1498 76023 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 0 0 MASQUERADE all -- * * 0.0.0.0/00.0.0.0/0 352c352 < 1498 76023 masq1 all -- * * 192.168.1.96/28 0.0.0.0/0 ---> 0 0 masq1 all -- * * 192.168.1.96/28 0.0.0.0/0357c357 < Chain PREROUTING (policy ACCEPT 111K packets, 34M bytes) ---> Chain PREROUTING (policy ACCEPT 112K packets, 34M bytes)359c359 < 111K 34M pretos all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 91 6492 pretos all -- * * 0.0.0.0/0 0.0.0.0/0361c361 < Chain INPUT (policy ACCEPT 2739 packets, 216K bytes) ---> Chain INPUT (policy ACCEPT 2993 packets, 230K bytes)367c367 < Chain OUTPUT (policy ACCEPT 2677 packets, 320K bytes) ---> Chain OUTPUT (policy ACCEPT 2945 packets, 353K bytes)369c369 < 2451 293K outtos all -- * * 0.0.0.0/0 0.0.0.0/0 ---> 64 6756 outtos all -- * * 0.0.0.0/0 0.0.0.0/0381,397c381,394 < unknown 47 583 src=192.168.1.97 dst=192.168.1.1 src=192.168.1.1 dst=192.168.1.97 use=1 < tcp 6 431857 ESTABLISHED src=192.168.1.101 dst=203.81.60.7 sport=2166 dport=80 src=203.81.60.7 dst=202.42.98.94 sport=80 dport=2166 [ASSURED] use=1 < tcp 6 431854 ESTABLISHED src=192.168.1.101 dst=63.208.235.96 sport=2164 dport=80 src=63.208.235.96 dst=202.42.98.94 sport=80 dport=2164 [ASSURED] use=1 < tcp 6 33 TIME_WAIT src=202.42.98.9 dst=203.120.90.192 sport=1028 dport=25 src=203.120.90.192 dst=202.42.98.9 sport=25 dport=1028 [ASSURED] use=1 < unknown 50 583 src=160.96.97.248 dst=202.42.98.9 [UNREPLIED] src=202.42.98.9 dst=160.96.97.248 use=1 < tcp 6 429780 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1298 dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1298 [ASSURED] use=1 < tcp 6 431857 ESTABLISHED src=192.168.1.101 dst=203.81.60.7 sport=2167 dport=80 src=203.81.60.7 dst=202.42.98.94 sport=80 dport=2167 [ASSURED] use=1 < icmp 1 13 src=192.168.2.97 dst=192.168.1.1 type=8 code=0 id=51835 [UNREPLIED] src=192.168.1.1 dst=192.168.2.97 type=0 code=0 id=51835 use=1 < tcp 6 431858 ESTABLISHED src=192.168.1.101 dst=203.81.60.6 sport=2169 dport=80 src=203.81.60.6 dst=202.42.98.94 sport=80 dport=2169 [ASSURED] use=1 < tcp 6 431983 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1297 dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1297 [ASSURED] use=1 < udp 17 107 src=202.42.98.9 dst=160.96.97.248 sport=500 dport=500 src=160.96.97.248 dst=202.42.98.9 sport=500 dport=500 [ASSURED] use=1 < tcp 6 429793 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1299 dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1299 [ASSURED] use=1 < tcp 6 431858 ESTABLISHED src=192.168.1.101 dst=209.67.78.2 sport=2165 dport=80 src=209.67.78.2 dst=202.42.98.94 sport=80 dport=2165 [ASSURED] use=1 < tcp 6 431858 ESTABLISHED src=192.168.1.101 dst=203.81.60.9 sport=2170 dport=80 src=203.81.60.9 dst=202.42.98.94 sport=80 dport=2170 [ASSURED] use=1 < udp 17 157 src=202.42.98.9 dst=192.169.34.181 sport=1024 dport=53 src=192.169.34.181 dst=202.42.98.9 sport=53 dport=1024 [ASSURED] use=1 < udp 17 38 src=192.168.1.101 dst=203.120.90.40 sport=1025 dport=53 src=203.120.90.40 dst=202.42.98.94 sport=53 dport=1025 [ASSURED] use=1 < tcp 6 431857 ESTABLISHED src=192.168.1.101 dst=68.142.225.184 sport=2161 dport=80 src=68.142.225.184 dst=202.42.98.94 sport=80 dport=2161 [ASSURED] use=1 ---> unknown 47 581 src=192.168.1.97 dst=192.168.1.1 src=192.168.1.1dst=192.168.1.97 use=1> tcp 6 431764 ESTABLISHED src=192.168.1.101 dst=203.81.60.7 sport=2166dport=80 src=203.81.60.7 dst=202.42.98.94 sport=80 dport=2166 [ASSURED] use=1> tcp 6 431761 ESTABLISHED src=192.168.1.101 dst=63.208.235.96 sport=2164dport=80 src=63.208.235.96 dst=202.42.98.94 sport=80 dport=2164 [ASSURED] use=1> unknown 50 581 src=160.96.97.248 dst=202.42.98.9 [UNREPLIED] src=202.42.98.9dst=160.96.97.248 use=1> tcp 6 429687 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1298dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1298 [ASSURED] use=1> tcp 6 431764 ESTABLISHED src=192.168.1.101 dst=203.81.60.7 sport=2167dport=80 src=203.81.60.7 dst=202.42.98.94 sport=80 dport=2167 [ASSURED] use=1> tcp 6 431765 ESTABLISHED src=192.168.1.101 dst=203.81.60.6 sport=2169dport=80 src=203.81.60.6 dst=202.42.98.94 sport=80 dport=2169 [ASSURED] use=1> tcp 6 431981 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1297dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1297 [ASSURED] use=1> udp 17 14 src=202.42.98.9 dst=160.96.97.248 sport=500 dport=500src=160.96.97.248 dst=202.42.98.9 sport=500 dport=500 [ASSURED] use=1> tcp 6 429700 ESTABLISHED src=192.168.1.101 dst=192.168.1.97 sport=1299dport=22 src=192.168.1.97 dst=192.168.1.101 sport=22 dport=1299 [ASSURED] use=1> tcp 6 431765 ESTABLISHED src=192.168.1.101 dst=209.67.78.2 sport=2165dport=80 src=209.67.78.2 dst=202.42.98.94 sport=80 dport=2165 [ASSURED] use=1> tcp 6 431765 ESTABLISHED src=192.168.1.101 dst=203.81.60.9 sport=2170dport=80 src=203.81.60.9 dst=202.42.98.94 sport=80 dport=2170 [ASSURED] use=1> udp 17 64 src=202.42.98.9 dst=192.169.34.181 sport=1024 dport=53src=192.169.34.181 dst=202.42.98.9 sport=53 dport=1024 [ASSURED] use=1> tcp 6 431764 ESTABLISHED src=192.168.1.101 dst=68.142.225.184 sport=2161dport=80 src=68.142.225.184 dst=202.42.98.94 sport=80 dport=2161 [ASSURED] use=1 431c428 < 11143209 89759 0 0 0 0 ---> 11161059 90008 0 0 0 0433c430 < 57537446 143308 0 0 0 0 ---> 57572672 143569 0 0 0 0443c440 < 57880247 139988 0 0 0 0 ---> 57882017 140011 0 0 0 0445c442 < 10947167 86771 0 0 2 1 ---> 10948691 86806 0 0 2 1455c452 < 3581 31 0 0 0 0 ---> 4085 34 0 0 0 0457c454 < 3249 30 0 0 0 0 ---> 4041 36 0 0 0 0461c458 < 0 0 0 0 0 0 ---> 252 3 0 0 0 0463c460 < 756 7 0 0 0 0 ---> 1080 10 0 0 0 0471c468 < /proc/sys/net/ipv4/conf/GDC1/rp_filter = 1 ---> /proc/sys/net/ipv4/conf/GDC1/rp_filter = 0491c488 < /proc/sys/net/ipv4/conf/ppp1/rp_filter = 1 ---> /proc/sys/net/ipv4/conf/ppp1/rp_filter = 0rx1000test:~# --- Tom Eastep <teastep@shorewall.net> wrote:> John Serink wrote: > > > > Ok, shorewall dump doesn''t appear to work on shorewall 2.2.3. > > > > On 2.2.3, "shorewall status" did something similar. > > -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 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>_______________________________________________> Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> Ok, here it is:Exactly what do you expect me to do with it? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> John Serink wrote: >> Ok, here it is: > > Exactly what do you expect me to do with it? > >I can tell you that the only thing that I see that *might* be significant is the change to /proc/sys/net/ipv4/conf/GDC1/rp_filter -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Tom Eastep wrote: >> John Serink wrote: >>> Ok, here it is: >> Exactly what do you expect me to do with it? >> >> > > I can tell you that the only thing that I see that *might* be > significant is the change to /proc/sys/net/ipv4/conf/GDC1/rp_filter >From what I''ve seen of your configuration and problems, I can only guess what is going on. But here''s a stab. a) Your routing is still not right. As a consequence, when traffic is received through the tunnel, it will be dropped as ''martian'' unless the tunnel''s rp_filter flag is turned off. b) It appears that you have set ROUTE_FILTER=Yes in shorewall.conf (why, I can only guess). That means that when you add the tunnel, route filtering is enabled by default and all traffic received through the tunnel is dropped. I don''t know if you also have martian logging enabled on the tunnel -- if you do then your log must contain ''martian'' log messages. c) When you "shorewall restart", rp_filter is being reset on all interfaces and traffic can then flow through the tunnel from the Cisco to the Linux box. d) Because of inadequate routing (which I brought to your attention a week ago), traffic from the Linux box to the Cisco is not going through the tunnel. So restarting Shorewall compensates for two configuration blunders and allows traffic to pass asymmetrically between the two boxes. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> T > b) It appears that you have set ROUTE_FILTER=Yes in shorewall.conf (why, > I can only guess).Debian may also enable this behavior by default. I don''t have a Debian system running at the moment so I can''t confirm or deny that... -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom: Thank you for the tips.... Will check out that ROUTE_FILTER=Yes setting in the config. Have set that to No. Your comment: a) Your routing is still not right No kidding....problem is, how can something so simple be wrong? Here is the routing table after a reboot: rx1000test:~# ip route 202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.150 192.168.1.0/28 via 160.96.97.248 dev ppp1 src 192.168.1.97 192.168.1.96/28 dev eth1 proto kernel scope link src 192.168.1.97 default dev ppp1 scope link Ok, the top is the dynamic IP pppoe link, the second one is the IPsec, the third is locally connected network(where my problem is) and the last is the default route. On the Cisco, if I remove the routes: ip route 192.168.1.96 255.255.255.240 Tunnel6 ip route 192.168.1.97 255.255.255.255 GigabitEthernet0/0 My host problem child host behind the linux router, 192.168.1.101, can ping anybody on the WAN over IPsec. Fine, now I replace the routes in the Cisco as I want the packets from there to go through the tunnel. and I do this on the Linux box: 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 brd + dev GDC1 ip route del 192.168.1.0/28 ip route add 192.168.1.0/28 dev GDC1 Not really rocket sience, I insert the ip_gre module, define the tunnel to the Cisco from IPSec endpoint to IPSec endpoint to ensure that the tunnel is riding inside the IPSec tunnel rather than beside it. I set the tunnel to up, I give the tunnel endpoint an IP, delete the route to 192.168.1.0/28 over the IPSec and replace it with one going over the tunnel. Easy, routing table now looks like this: rx1000test:~# ip route 202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.150 192.168.1.0/28 dev GDC1 scope link 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 Perfect. couldn''t be simpler. And from the linux router, 192.168.1.97, I can ping everything and using tcpdump -i GDC1, that which should traverse the tunnel is doing so. Fine. But that''s the boring bit.... Now lets move to the problem child host 192.168.1.101 behind the Linux gateway.>From here I can ping the following:The Linux Eth1 interface, the linux side of the tunnel, the Cisco side of the tunnel(I can see this ping go into and return through the tunnel from tcpdump -i GDC1. Watching the Cisco debug tunnels, I can see all the action as well). Now, if form host 192.168.1.101 I try to ping the cisco gig0/0 interface, the one on network 192.168.1.0/28, 192.168.1.1 I get this: C:\Documents and Settings\jserink>ping 192.168.1.1 -n 2 Pinging 192.168.1.1 with 32 bytes of data: Request timed out. Request timed out. Ping statistics for 192.168.1.1: Packets: Sent = 2, Received = 0, Lost = 2 (100% loss), What''s even more wierd, look at tcpdump -i GDC1: 13:43:25.225826 IP 192.168.1.1 > 192.168.1.101: icmp 40: echo reply seq 8960 13:43:30.595917 IP 192.168.1.1 > 192.168.1.101: icmp 40: echo reply seq 9216 Eh? The echo request DID NOT GO THROUGH THE TUNNEL, but the echo reply did. WTF???? Look at the routing table, makes no sense. Nothing is showing up in the syslog either and doing shorewall clear doesn''t change anything, behavior the same. On the Cisco side, it looks like this: *Jul 23 05:52:32.082: Tunnel6: GRE/IP encapsulated 192.168.1.1->192.168.1.97 (linktype=7, len=84) *Jul 23 05:52:37.454: Tunnel6: GRE/IP encapsulated 192.168.1.1->192.168.1.97 (linktype=7, len=84) Which is exactly what tcpdump -i GDC1 told me, response went through the tunnel, the request did not. But that''s not all, there was a response to the ping....where did it go? 192.168.1.101 didn''t receive it and there is clearly a route in the linux box telling it where 192.168.1.101 is, so where''s the ping response? Ok you say, can I ping the tunnel from 192.168.1.101? Sure, I''ll ping the cisco end, 192.168.2.110: C:\Documents and Settings\jserink>ping 192.168.2.110 -n 2 Pinging 192.168.2.110 with 32 bytes of data: Reply from 192.168.2.110: bytes=32 time=17ms TTL=254 Reply from 192.168.2.110: bytes=32 time=15ms TTL=254 Ping statistics for 192.168.2.110: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 15ms, Maximum = 17ms, Average = 16ms And the tcpdump -i GDC1: 13:49:02.334480 IP 192.168.1.101 > 192.168.2.110: icmp 40: echo request seq 10496 13:49:02.349875 IP 192.168.2.110 > 192.168.1.101: icmp 40: echo reply seq 10496 13:49:03.337212 IP 192.168.1.101 > 192.168.2.110: icmp 40: echo request seq 10752 13:49:03.351350 IP 192.168.2.110 > 192.168.1.101: icmp 40: echo reply seq 10752 Just like its suppose to be, request through the tunnel, response through the tunnel. Cisco side: *Jul 23 05:58:09.189: Tunnel6: GRE/IP to classify 192.168.1.97->192.168.1.1 (len=84 type=0x800 ttl=254 tos=0x0) *Jul 23 05:58:09.189: Tunnel6: GRE/IP to decaps 192.168.1.97->192.168.1.1 (len=84 ttl=254) *Jul 23 05:58:09.189: Tunnel6: GRE decapsulated IP 192.168.1.101->192.168.2.110 (len=60, ttl=126) *Jul 23 05:58:09.189: Tunnel6: GRE/IP encapsulated 192.168.1.1->192.168.1.97 (linktype=7, len=84) *Jul 23 05:58:10.189: Tunnel6: GRE/IP to classify 192.168.1.97->192.168.1.1 (len=84 type=0x800 ttl=254 tos=0x0) *Jul 23 05:58:10.193: Tunnel6: GRE/IP to decaps 192.168.1.97->192.168.1.1 (len=84 ttl=254) *Jul 23 05:58:10.193: Tunnel6: GRE decapsulated IP 192.168.1.101->192.168.2.110 (len=60, ttl=126) *Jul 23 05:58:10.193: Tunnel6: GRE/IP encapsulated 192.168.1.1->192.168.1.97 (linktype=7, len=84) Just like ti should be. Now, this behaviour of request no traversing the tunnel, the response traversing the tunnel and the response getting lost in the linux box is the same if I try and ping any host on 192.168.1.0/28 from 192.168.1.101. If I ping from 192.168.1.97, the link gateway, its fine. On 192.168.1.97: rx1000test:~# ip addr 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 16: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1452 qdisc pfifo_fast qlen 3 link/ppp inet 210.24.254.150 peer 202.42.98.1/32 scope global ppp1 17: gre0: <NOARP> mtu 1476 qdisc noop link/gre 0.0.0.0 brd 0.0.0.0 18: GDC1@NONE: <POINTOPOINT,NOARP,PROMISC,UP> mtu 1428 qdisc noqueue link/gre 192.168.1.97 peer 192.168.1.1 inet 192.168.2.97/28 brd 192.168.2.111 scope global GDC1 I have been banging my head against the wall with this one for over a week. So when you tell me my routing is not right, can''t argue with you at all. But having said that, what''s wrong with it? Its simple as hell. How is it that pings, anything in fact, from 192.168.1.101 does not go to 192.168.1.0/28 via the tunnel? The routing table says it must....but it doesn''t. And then the response which clearly comes back via the tunnel never gets to 192.168.1.101. Am I confused? You bet I am. John --- Tom Eastep <teastep@shorewall.net> wrote:> Tom Eastep wrote: > > Tom Eastep wrote: > >> John Serink wrote: > >>> Ok, here it is: > >> Exactly what do you expect me to do with it? > >> > >> > > > > I can tell you that the only thing that I see that *might* be > > significant is the change to /proc/sys/net/ipv4/conf/GDC1/rp_filter > > > > From what I''ve seen of your configuration and problems, I can only guess > what is going on. But here''s a stab. > > a) Your routing is still not right. As a consequence, when traffic is > received through the tunnel, it will be dropped as ''martian'' unless the > tunnel''s rp_filter flag is turned off. > > b) It appears that you have set ROUTE_FILTER=Yes in shorewall.conf (why, > I can only guess). That means that when you add the tunnel, route > filtering is enabled by default and all traffic received through the > tunnel is dropped. I don''t know if you also have martian logging enabled > on the tunnel -- if you do then your log must contain ''martian'' log > messages. > > c) When you "shorewall restart", rp_filter is being reset on all > interfaces and traffic can then flow through the tunnel from the Cisco > to the Linux box. > > d) Because of inadequate routing (which I brought to your attention a > week ago), traffic from the Linux box to the Cisco is not going through > the tunnel. > > So restarting Shorewall compensates for two configuration blunders and > allows traffic to pass asymmetrically between the two boxes. > > -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 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>_______________________________________________> Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> > I have been banging my head against the wall with this one for over a week. > So when you tell me my routing is not right, can''t argue with you at all. But > having said that, what''s wrong with it? Its simple as hell. How is it that > pings, anything in fact, from 192.168.1.101 does not go to 192.168.1.0/28 via > the tunnel? The routing table says it must....but it doesn''t. And then the > response which clearly comes back via the tunnel never gets to 192.168.1.101. > > Am I confused? You bet I am. >What is the output of "setkey -DP"? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> John Serink wrote: >> I have been banging my head against the wall with this one for over a week. >> So when you tell me my routing is not right, can''t argue with you at all. But >> having said that, what''s wrong with it? Its simple as hell. How is it that >> pings, anything in fact, from 192.168.1.101 does not go to 192.168.1.0/28 via >> the tunnel? The routing table says it must....but it doesn''t. And then the >> response which clearly comes back via the tunnel never gets to 192.168.1.101. >> >> Am I confused? You bet I am. >> > > What is the output of "setkey -DP"? >You need to install ipsec-tools in order to have access to that command. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom:
Ok, before I have configured my tunnel:
rx1000test:~# setkey -DP
192.168.1.0/28[any] 192.168.1.96/28[any] any
in ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006
lifetime: 0(s) validtime: 0(s)
spid=744 seq=10 pid=16069
refcnt=2
192.168.1.96/28[any] 192.168.1.0/28[any] any
out ipsec
esp/tunnel/210.24.254.149-160.96.97.248/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006
lifetime: 0(s) validtime: 0(s)
spid=737 seq=9 pid=16069
refcnt=3
192.168.1.0/28[any] 192.168.1.96/28[any] any
fwd ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=754 seq=8 pid=16069
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=723 seq=7 pid=16069
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=707 seq=6 pid=16069
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=691 seq=5 pid=16069
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:47 2006
lifetime: 0(s) validtime: 0(s)
spid=675 seq=4 pid=16069
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=732 seq=3 pid=16069
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=716 seq=2 pid=16069
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=700 seq=1 pid=16069
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:48 2006
lifetime: 0(s) validtime: 0(s)
spid=684 seq=0 pid=16069
refcnt=1
(That is to say, pings to 192.168.1.0/28 do NOT traverse the tunnel from
192.168.1.97).
COnfiguring the GDC1 tunnel:
rx1000test:~# ip tun del GDC1
rx1000test:~# modprobe ip_gre
rx1000test:~# ip tunnel add GDC1 mode gre remote 192.168.1.1 local 192.168.1.97
ttl 255
rx1000test:~# ip link set GDC1 up
rx1000test:~# ip addr add 192.168.2.97/28 brd + dev GDC1
rx1000test:~# ip route del 192.168.1.0/28
rx1000test:~# ip route add 192.168.1.0/28 dev GDC1
rx1000test:~# ping 192.168.1.2 -w 2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
--- 192.168.1.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms
rx1000test:~# ping 192.168.1.2 -w 2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
--- 192.168.1.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms
rx1000test:~# setkey -DP
192.168.1.0/28[any] 192.168.1.96/28[any] any
in ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:29:17 2006
lifetime: 0(s) validtime: 0(s)
spid=744 seq=10 pid=16646
refcnt=3
192.168.1.96/28[any] 192.168.1.0/28[any] any
out ipsec
esp/tunnel/210.24.254.149-160.96.97.248/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:30:39 2006
lifetime: 0(s) validtime: 0(s)
spid=737 seq=9 pid=16646
refcnt=6
192.168.1.0/28[any] 192.168.1.96/28[any] any
fwd ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=754 seq=8 pid=16646
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=723 seq=7 pid=16646
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=707 seq=6 pid=16646
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=691 seq=5 pid=16646
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:47 2006
lifetime: 0(s) validtime: 0(s)
spid=675 seq=4 pid=16646
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=732 seq=3 pid=16646
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=716 seq=2 pid=16646
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=700 seq=1 pid=16646
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:48 2006
lifetime: 0(s) validtime: 0(s)
spid=684 seq=0 pid=16646
refcnt=1
No ping replies, restarting shorewall:
rx1000test:~# shorewall -f start
Restoring Shorewall...
Loading kernel modules...
Restoring Proxy ARP...
Restoring one-to-one NAT...
Restoring ARP filtering...
Restoring Route Filtering...
Restoring Accept Source Routing...
Restoring IP Forwarding...
Restoring Masquerading/SNAT...
Restoring Netfilter Configuration...
Shorewall restored from /var/lib/shorewall/restore
rx1000test:~# ping 192.168.1.2 -w 2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=14.9 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=14.1 ms
--- 192.168.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 14.121/14.525/14.929/0.404 ms
There we are, all up and traversing the tunnel.
For completeness, setkey -DP.
rx1000test:~# setkey -DP
192.168.1.0/28[any] 192.168.1.96/28[any] any
in ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:31:51 2006
lifetime: 0(s) validtime: 0(s)
spid=744 seq=10 pid=17000
refcnt=4
192.168.1.96/28[any] 192.168.1.0/28[any] any
out ipsec
esp/tunnel/210.24.254.149-160.96.97.248/unique#16385
created: Jul 24 22:06:48 2006 lastused: Jul 24 22:31:51 2006
lifetime: 0(s) validtime: 0(s)
spid=737 seq=9 pid=17000
refcnt=6
192.168.1.0/28[any] 192.168.1.96/28[any] any
fwd ipsec
esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
created: Jul 24 22:06:48 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=754 seq=8 pid=17000
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=723 seq=7 pid=17000
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=707 seq=6 pid=17000
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=691 seq=5 pid=17000
refcnt=1
(per-socket policy)
in none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:47 2006
lifetime: 0(s) validtime: 0(s)
spid=675 seq=4 pid=17000
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=732 seq=3 pid=17000
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=716 seq=2 pid=17000
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused:
lifetime: 0(s) validtime: 0(s)
spid=700 seq=1 pid=17000
refcnt=1
(per-socket policy)
out none
created: Jul 24 22:06:45 2006 lastused: Jul 24 22:06:48 2006
lifetime: 0(s) validtime: 0(s)
spid=684 seq=0 pid=17000
refcnt=1
Just to complete the picture:
rx1000test:~# ip route
202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.149
192.168.1.0/28 dev GDC1 scope link
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
Cheers,
John
--- Tom Eastep <teastep@shorewall.net> wrote:
> Tom Eastep wrote:
> > John Serink wrote:
> >> I have been banging my head against the wall with this one for
over a
> week.
> >> So when you tell me my routing is not right, can''t argue
with you at all.
> But
> >> having said that, what''s wrong with it? Its simple as
hell. How is it that
> >> pings, anything in fact, from 192.168.1.101 does not go to
192.168.1.0/28
> via
> >> the tunnel? The routing table says it must....but it
doesn''t. And then the
> >> response which clearly comes back via the tunnel never gets to
> 192.168.1.101.
> >>
> >> Am I confused? You bet I am.
> >>
> >
> > What is the output of "setkey -DP"?
> >
>
> You need to install ipsec-tools in order to have access to that command.
>
> -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
>
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
John Serink wrote:> Hi Tom: > > Ok, before I have configured my tunnel: > rx1000test:~# setkey -DP > 192.168.1.0/28[any] 192.168.1.96/28[any] any > in ipsec > esp/tunnel/160.96.97.248-210.24.254.149/unique#16385 > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006 > lifetime: 0(s) validtime: 0(s) > spid=744 seq=10 pid=16069 > refcnt=2So any incoming traffic from 192.168.1.0/28 to 192.168.1.96/28 that wasn''t decrypted from an esp tunnel-mode encapsulation from 160.96.97.248->210.24.254.149 will be dropped. That means that traffic from 192.168.1.0/28 to 192.168.1.96/28 that comes through the GRE tunnel will be dropped.> 192.168.1.96/28[any] 192.168.1.0/28[any] any > out ipsec > esp/tunnel/210.24.254.149-160.96.97.248/unique#16385 > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006 > lifetime: 0(s) validtime: 0(s) > spid=737 seq=9 pid=16069 > refcnt=3And any outgoing traffic from 192.168.1.96/28 to 192.168.1.0/28 will be encrypted/encapsulated using ESP and tunnel mode and will be sent to 160.96.97.248 (via your ppp interface). It will not go through the GRE tunnel. I believe that the above explains why you are seeing the problems at host 192.168.1.101.> > (That is to say, pings to 192.168.1.0/28 do NOT traverse the tunnel from > 192.168.1.97). > COnfiguring the GDC1 tunnel: > rx1000test:~# ip tun del GDC1 > rx1000test:~# modprobe ip_gre > rx1000test:~# ip tunnel add GDC1 mode gre remote 192.168.1.1 local 192.168.1.97 > ttl 255 > rx1000test:~# ip link set GDC1 up > rx1000test:~# ip addr add 192.168.2.97/28 brd + dev GDC1I don''t understand what the above line is supposed to be accomplishing....> rx1000test:~# ip route del 192.168.1.0/28 > rx1000test:~# ip route add 192.168.1.0/28 dev GDC1The above two commands can be combined into a single "ip route replace..." command.> rx1000test:~# ping 192.168.1.2 -w 2 > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > > --- 192.168.1.2 ping statistics --- > 2 packets transmitted, 0 received, 100% packet loss, time 1001ms > > rx1000test:~# ping 192.168.1.2 -w 2 > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > > --- 192.168.1.2 ping statistics --- > 2 packets transmitted, 0 received, 100% packet loss, time 1007ms > > rx1000test:~# setkey -DPUnless you reconfigure IPSEC, the SPD does not change (and it didn''t).> > > No ping repliesLooking at a ''diff'' between two sets of ''shorewall status'' output without being able to see either one presents a world-class guessing game but that''s all you''ve given me to go on; so at this point, I think that you have: /proc/sys/net/ipv4/conf/GDC1/rp_filter=1 And your routing table looks like: 202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.149 192.168.1.0/28 dev GDC1 scope link 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 I don''t know what the other /proc/sys/net/ipvr/conf/*/rp_filter settings are. I don''t see what that should be a problem but if you would turn on martian logging on all interfaces at this point, you could confirm that the setting of rp_filter is what "shorewall restart" is "correcting". for file in /proc/sys/net/ipv4/conf/*; do echo 1 > $file/log_martians done You should see the kernel logging ''martian'' messages if in fact the setting of rp_filter is what is causing this to not work. Did you confirm that you have ROUTE_FILTER=Yes in shorewall.conf? If it is not set, then do you have "routefilter" specified on any of your interfaces in /etc/shorewall/interfaces?> restarting shorewall: > rx1000test:~# shorewall -f start > Restoring Shorewall... > Loading kernel modules... > Restoring Proxy ARP... > Restoring one-to-one NAT... > Restoring ARP filtering... > Restoring Route Filtering...The above progress message indicates that: a) ROUTE_FILTER=Yes in shorewall.conf; and/or b) One or more interfaces have ''routefilter'' specified in /etc/shorewall/interfaces. Which is why I ask the questions above...> Restoring Accept Source Routing... > Restoring IP Forwarding... > Restoring Masquerading/SNAT... > Restoring Netfilter Configuration... > Shorewall restored from /var/lib/shorewall/restore > rx1000test:~# ping 192.168.1.2 -w 2 > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=14.9 ms > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=14.1 ms > > --- 192.168.1.2 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms > rtt min/avg/max/mdev = 14.121/14.525/14.929/0.404 ms > > There we are, all up and traversing the tunnel. > For completeness, setkey -DP. >Again, that is just a waste of bandwidth. I don''t understand what you are trying to accomplish with your GRE tunnel inside an IPSEC tunnel. I guess it is so you can use routing like you did under the 2.4 kernels? If I were going to do that, I would define my security policies so they applied only to GRE traffic between the two endpoint hosts; that way, the traffic between the two subnets would just be routed through the GRE tunnel and the GRE packets would be encrypted/encapsulated by IPSEC. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom: This mail got me thinking, comments below: --- Tom Eastep <teastep@shorewall.net> wrote:> John Serink wrote: > > Hi Tom: > > > > Ok, before I have configured my tunnel: > > rx1000test:~# setkey -DP > > 192.168.1.0/28[any] 192.168.1.96/28[any] any > > in ipsec > > esp/tunnel/160.96.97.248-210.24.254.149/unique#16385 > > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006 > > lifetime: 0(s) validtime: 0(s) > > spid=744 seq=10 pid=16069 > > refcnt=2 > > So any incoming traffic from 192.168.1.0/28 to 192.168.1.96/28 that wasn''t > decrypted from an esp tunnel-mode encapsulation from > 160.96.97.248->210.24.254.149 will be dropped. That means that traffic from > 192.168.1.0/28 to 192.168.1.96/28 that comes through the GRE tunnel will be > dropped.But the tunnel itself is encrypted. The tunnel is going over the IPSec, not beside it.> > 192.168.1.96/28[any] 192.168.1.0/28[any] any > > out ipsec > > esp/tunnel/210.24.254.149-160.96.97.248/unique#16385 > > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006 > > lifetime: 0(s) validtime: 0(s) > > spid=737 seq=9 pid=16069 > > refcnt=3 > > And any outgoing traffic from 192.168.1.96/28 to 192.168.1.0/28 will be > encrypted/encapsulated using ESP and tunnel mode and will be sent to > 160.96.97.248 (via your ppp interface). It will not go through the GRE > tunnel.It does go via the tunnel, I can see that using tcpdump -i GDC1 along with tcpdump -i ppp1 on a different terminal. Only a single ESP packet leaves ppp1 and then a single one returns and the ping succeeds. When pinging from 192.168.1.197 to anyone else.> > I believe that the above explains why you are seeing the problems at host > 192.168.1.101.Hmmmm. I think its because the output of setkey shows that only traffic from 192.168.1.0/28 is allowed out of the tunnel. The Tunnel, 192.168.2.96/28 is not in that range so the packets are silently dropped. The reason the packets got into the tunnel in the first place must be because the other side is not openswan, its Cisco.> > > > (That is to say, pings to 192.168.1.0/28 do NOT traverse the tunnel from > > 192.168.1.97). > > COnfiguring the GDC1 tunnel: > > rx1000test:~# ip tun del GDC1 > > rx1000test:~# modprobe ip_gre > > rx1000test:~# ip tunnel add GDC1 mode gre remote 192.168.1.1 local > 192.168.1.97 > > ttl 255 > > rx1000test:~# ip link set GDC1 up > > rx1000test:~# ip addr add 192.168.2.97/28 brd + dev GDC1 > > I don''t understand what the above line is supposed to be accomplishing....It gives the GDC1 tunnel interface and IP on this host. Its right out of th eIProute 2 docs,> > rx1000test:~# ip route del 192.168.1.0/28 > > rx1000test:~# ip route add 192.168.1.0/28 dev GDC1 > > The above two commands can be combined into a single "ip route replace..." > command.Roger that.> > > rx1000test:~# ping 192.168.1.2 -w 2 > > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > > > > --- 192.168.1.2 ping statistics --- > > 2 packets transmitted, 0 received, 100% packet loss, time 1001ms > > > > rx1000test:~# ping 192.168.1.2 -w 2 > > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > > > > --- 192.168.1.2 ping statistics --- > > 2 packets transmitted, 0 received, 100% packet loss, time 1007ms > > > > rx1000test:~# setkey -DP > > Unless you reconfigure IPSEC, the SPD does not change (and it didn''t).Ok, roger that.> > > > > > No ping replies > > Looking at a ''diff'' between two sets of ''shorewall status'' output without > being > able to see either one presents a world-class guessing game but that''s all > you''ve given me to go on; so at this point, I think that you have: > > /proc/sys/net/ipv4/conf/GDC1/rp_filter=1 > > And your routing table looks like: > > 202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.149 > 192.168.1.0/28 dev GDC1 scope link > 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 > > I don''t know what the other /proc/sys/net/ipvr/conf/*/rp_filter settings are. > > I don''t see what that should be a problem but if you would turn on martian > logging on all interfaces at this point, you could confirm that the setting > of > rp_filter is what "shorewall restart" is "correcting". > > for file in /proc/sys/net/ipv4/conf/*; do > echo 1 > $file/log_martians > done > > You should see the kernel logging ''martian'' messages if in fact the setting > of > rp_filter is what is causing this to not work. Did you confirm that you have > ROUTE_FILTER=Yes in shorewall.conf? If it is not set, then do you have > "routefilter" specified on any of your interfaces in > /etc/shorewall/interfaces?It is set to YES, confirm. No routefileter option is set on any interface.> > > > restarting shorewall: > > rx1000test:~# shorewall -f start > > Restoring Shorewall... > > Loading kernel modules... > > Restoring Proxy ARP... > > Restoring one-to-one NAT... > > Restoring ARP filtering... > > Restoring Route Filtering... > > The above progress message indicates that: > > a) ROUTE_FILTER=Yes in shorewall.conf; and/or > b) One or more interfaces have ''routefilter'' specified in > /etc/shorewall/interfaces. > > Which is why I ask the questions above... > > > Restoring Accept Source Routing... > > Restoring IP Forwarding... > > Restoring Masquerading/SNAT... > > Restoring Netfilter Configuration... > > Shorewall restored from /var/lib/shorewall/restore > > rx1000test:~# ping 192.168.1.2 -w 2 > > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=14.9 ms > > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=14.1 ms > > > > --- 192.168.1.2 ping statistics --- > > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms > > rtt min/avg/max/mdev = 14.121/14.525/14.929/0.404 ms > > > > There we are, all up and traversing the tunnel. > > For completeness, setkey -DP. > > > > Again, that is just a waste of bandwidth. > > I don''t understand what you are trying to accomplish with your GRE tunnel > inside > an IPSEC tunnel.I need an interface to be able to do tc on. Right now I only have ppp1 and by the time the traffic hits there, its already encrypted so that doesn''t help me much.> I guess it is so you can use routing like you did under the > 2.4 > kernels?Kind of, see above.> If I were going to do that, I would define my security policies so > they > applied only to GRE traffic between the two endpoint hosts; that way, the > traffic between the two subnets would just be routed through the GRE tunnel > and > the GRE packets would be encrypted/encapsulated by IPSEC.I thought that was what I was doing? I''m not doing that?> -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 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>_______________________________________________> Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Tom:
It was my ipsec.conf file, I need to change these two lines from:
leftsubnet=192.168.1.97/28
rightsubnet=192.168.1.1/28
To:
leftsubnet=192.168.1.97/32
rightsubnet=192.168.1.1/32
Once I did that, it all works perfectly.
I want really thank you for the help, you went way out of your way.
Thankyou very much, all the best.
Cheers,
John
--- Tom Eastep <teastep@shorewall.net> wrote:
> John Serink wrote:
> > Hi Tom:
> >
> > Ok, before I have configured my tunnel:
> > rx1000test:~# setkey -DP
> > 192.168.1.0/28[any] 192.168.1.96/28[any] any
> > in ipsec
> > esp/tunnel/160.96.97.248-210.24.254.149/unique#16385
> > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006
> > lifetime: 0(s) validtime: 0(s)
> > spid=744 seq=10 pid=16069
> > refcnt=2
>
> So any incoming traffic from 192.168.1.0/28 to 192.168.1.96/28 that
wasn''t
> decrypted from an esp tunnel-mode encapsulation from
> 160.96.97.248->210.24.254.149 will be dropped. That means that traffic
from
> 192.168.1.0/28 to 192.168.1.96/28 that comes through the GRE tunnel will be
> dropped.
>
> > 192.168.1.96/28[any] 192.168.1.0/28[any] any
> > out ipsec
> > esp/tunnel/210.24.254.149-160.96.97.248/unique#16385
> > created: Jul 24 22:06:48 2006 lastused: Jul 24 22:27:46 2006
> > lifetime: 0(s) validtime: 0(s)
> > spid=737 seq=9 pid=16069
> > refcnt=3
>
> And any outgoing traffic from 192.168.1.96/28 to 192.168.1.0/28 will be
> encrypted/encapsulated using ESP and tunnel mode and will be sent to
> 160.96.97.248 (via your ppp interface). It will not go through the GRE
> tunnel.
>
> I believe that the above explains why you are seeing the problems at host
> 192.168.1.101.
>
> >
> > (That is to say, pings to 192.168.1.0/28 do NOT traverse the tunnel
from
> > 192.168.1.97).
> > COnfiguring the GDC1 tunnel:
> > rx1000test:~# ip tun del GDC1
> > rx1000test:~# modprobe ip_gre
> > rx1000test:~# ip tunnel add GDC1 mode gre remote 192.168.1.1 local
> 192.168.1.97
> > ttl 255
> > rx1000test:~# ip link set GDC1 up
> > rx1000test:~# ip addr add 192.168.2.97/28 brd + dev GDC1
>
> I don''t understand what the above line is supposed to be
accomplishing....
>
> > rx1000test:~# ip route del 192.168.1.0/28
> > rx1000test:~# ip route add 192.168.1.0/28 dev GDC1
>
> The above two commands can be combined into a single "ip route
replace..."
> command.
>
> > rx1000test:~# ping 192.168.1.2 -w 2
> > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
> >
> > --- 192.168.1.2 ping statistics ---
> > 2 packets transmitted, 0 received, 100% packet loss, time 1001ms
> >
> > rx1000test:~# ping 192.168.1.2 -w 2
> > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
> >
> > --- 192.168.1.2 ping statistics ---
> > 2 packets transmitted, 0 received, 100% packet loss, time 1007ms
> >
> > rx1000test:~# setkey -DP
>
> Unless you reconfigure IPSEC, the SPD does not change (and it
didn''t).
>
> >
> >
> > No ping replies
>
> Looking at a ''diff'' between two sets of
''shorewall status'' output without
> being
> able to see either one presents a world-class guessing game but
that''s all
> you''ve given me to go on; so at this point, I think that you have:
>
> /proc/sys/net/ipv4/conf/GDC1/rp_filter=1
>
> And your routing table looks like:
>
> 202.42.98.1 dev ppp1 proto kernel scope link src 210.24.254.149
> 192.168.1.0/28 dev GDC1 scope link
> 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
>
> I don''t know what the other /proc/sys/net/ipvr/conf/*/rp_filter
settings are.
>
> I don''t see what that should be a problem but if you would turn on
martian
> logging on all interfaces at this point, you could confirm that the setting
> of
> rp_filter is what "shorewall restart" is "correcting".
>
> for file in /proc/sys/net/ipv4/conf/*; do
> echo 1 > $file/log_martians
> done
>
> You should see the kernel logging ''martian'' messages if
in fact the setting
> of
> rp_filter is what is causing this to not work. Did you confirm that you
have
> ROUTE_FILTER=Yes in shorewall.conf? If it is not set, then do you have
> "routefilter" specified on any of your interfaces in
> /etc/shorewall/interfaces?
>
>
> > restarting shorewall:
> > rx1000test:~# shorewall -f start
> > Restoring Shorewall...
> > Loading kernel modules...
> > Restoring Proxy ARP...
> > Restoring one-to-one NAT...
> > Restoring ARP filtering...
> > Restoring Route Filtering...
>
> The above progress message indicates that:
>
> a) ROUTE_FILTER=Yes in shorewall.conf; and/or
> b) One or more interfaces have ''routefilter'' specified in
> /etc/shorewall/interfaces.
>
> Which is why I ask the questions above...
>
> > Restoring Accept Source Routing...
> > Restoring IP Forwarding...
> > Restoring Masquerading/SNAT...
> > Restoring Netfilter Configuration...
> > Shorewall restored from /var/lib/shorewall/restore
> > rx1000test:~# ping 192.168.1.2 -w 2
> > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
> > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=14.9 ms
> > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=127 time=14.1 ms
> >
> > --- 192.168.1.2 ping statistics ---
> > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms
> > rtt min/avg/max/mdev = 14.121/14.525/14.929/0.404 ms
> >
> > There we are, all up and traversing the tunnel.
> > For completeness, setkey -DP.
> >
>
> Again, that is just a waste of bandwidth.
>
> I don''t understand what you are trying to accomplish with your GRE
tunnel
> inside
> an IPSEC tunnel. I guess it is so you can use routing like you did under
the
> 2.4
> kernels? If I were going to do that, I would define my security policies so
> they
> applied only to GRE traffic between the two endpoint hosts; that way, the
> traffic between the two subnets would just be routed through the GRE tunnel
> and
> the GRE packets would be encrypted/encapsulated by IPSEC.
>
> -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
>
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hello John, John Serink wrote:> Hi Tom: > > This mail got me thinking, comments below: >To summarize: a) If you don''t like having to restart Shorewall after adding the tunnel, set ROUTE_FILTER=No in shorewall.conf. After making that change, you will need to manually reset the default rp_filter flags: echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter (alternatively, you can re-boot). b) John, I''m not an IPSEC expert and I don''t currently have an IPSEC installation to experiment with. So I''m going to stop trying to give you advise about how I believe that IPSEC works; there are clearly better forums than the Shorewall list for you to consult for help with those issues. -Tom PS -- what I know about IPSEC is pretty well encapsulated in this presentation: http://www.shorewall.net/LinuxFest2005.pdf -- 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi John, John Serink wrote:> Hi Tom: > > It was my ipsec.conf file, I need to change these two lines from: > leftsubnet=192.168.1.97/28 > rightsubnet=192.168.1.1/28 > > To: > > leftsubnet=192.168.1.97/32 > rightsubnet=192.168.1.1/32 > > Once I did that, it all works perfectly.That''s great news because as I wrote in my last response to you, you had reached the end of my IPSEC knowledge.> > I want really thank you for the help, you went way out of your way. > Thankyou very much, all the best. > >You''re welcome. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV