Michael D. Schleif wrote:
Charles Steinkuehler wrote:
 Regardless, the firewall rules on pinktrout are a
"Must see", especially given the log errors.
Simply ipchains -nvL ???
Yes, that will work fine. I usually like the output of "net ipfilter list", which also includes port-forwarding settings, but those shouldn't matter here...

The complete output of "ip addr" and "ip route" from *BOTH* systems
would also be very helpful.
ip route is complete in last post; ip addr will go on the webpage, too .
. .
Yes, and you posted ip addr info previously. However, it's always nice to have everything posted in one place (or e-mail), and posting everything at once also creates less uncertainty about any changes that may (or may not) have taken place between various posts.

> [7] kern.log:
>
> root@pinktrout:/root
> # tail -f /var/log/kern.log
> Nov 12 20:41:18 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62911 F=0x0000 T=54 (#56)
> Nov 12 20:41:19 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62913 F=0x0000 T=54 (#56)
> Nov 12 20:41:20 pinktrout kernel: Packet log: input DENY wan1 PROTO=50 64.4.222.157:65535 144.228.51.210:65535 L=136 S=0x00 I=62915 F=0x0000 T=54 (#56)

This is Very Bad...
Yes, that is why I posted ;>

I thought that protocols 50 & 51 *should* be coming in on ipsec0 ???
Um...not exactly. You should *NEVER* see protocol 50 or 51 traffic on ipsec0 unless you are specifically building an IPSec tunnel inside of another IPSec tunnel (ie double-encrypting). The protocol 50 packets hit your external interface, get decrypted by IPSec, and the clear-text packets are then spit out the ipsec0 interface. Transmitted packets are just the reverse (clear-text packets are sent to ipsec0, which encrypts them and spits the protocol 50 packets out your external I/F).

Or, is it _proper_ to open that up independent of all interfaces?
...don't understand this question. If the above description doesn't help, please re-phrase.

Conf files look OK.  I thought you were going to be using PSK to talk to
the Cisco (you have RSA sig-keys in the conf file), but as long as the
tunnel comes up, you should be OK for testing...
I decided to modify a _working_ gw-gw tunnel and assumed, as you
apparently concur, that I can ignore psk for now . . .
Yes, this should cause no real trouble, since both ends have fixed IPs. Be aware, however, that if you were working with a dynamic connection, there are lots of low-level differences between using RSA and PSK.

The main problem I see is the denied IPSec traffic on pinktrout.  You
don't mention which machines you tried to ping from/to...remember,
you'll only be able to ping from pinktrout to machines on the
192.168.1.0/24 net other than bluetrout.
I have a special _ip route change_ cli that adds the DCD's to the ipsec0
routing.

I tried pinging from both ends.  tcpdump saw the pings enter the tunnel;
but, nothing came out either tunnel.
...Becuase pinktrout is dropping the encrypted traffic before it can be decrypted by ipsec.

I did not find any errors logged on bluetrout -- pinktrout complains
about protocol 50.
Which all makes sense, given pinktrout is dropping the inbound packets.

Once you get pinktrout talking to the remote network, you can start
adding masq rules to try and get the networks behind pinktrout talking
to the far end.  With any luck, that should just work with the
appropriate masq rule added to the forward rule chain.
Actually, I have already added a masq rule.  Apparently, if I open up
protocol 50 -- properly -- you think that all will fall into place, as I
hope?
I think so, but w/o seeing your ipchains rules (and not having setup a masqueraded ipsec connection personally), it's hard to say for sure.

--
Charles Steinkuehler
[EMAIL PROTECTED]




-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to