At a loss - IPSEC

oh, forgot to add, nothing related is logged in packetfilter-violation log for either ASL box...

post more network details please. i.e. network addresses, netmasks, routing tables from each box etc.

you've said that you have packet rules for network A network B, what do you mean by "ExternAExternB"?, do you have to add rules for the external IP so that it opens the IPSec VPN ports?

details (NOTE - Both ASL boxes are on the same ISP, which is why in routing tables, next hop is the same on both boxes):

ASL1 External interface: xxx.xxx.xxx.xxx
ASL1 eth0_network: 192.168.1.0
ASL1 eth0_interface: 192.168.1.254

ASL1 VPN Routes:
 0          192.168.1.0/24     -> 192.168.2.0/24     => tun0x1002@yyy.yyy.yyy.yyy

ASL1 Routing Table:
66.11.172.1 dev ppp0  scope link 
66.11.172.1 dev ipsec0  proto kernel  scope link  src xxx.xxx.xxx.xxx
192.168.2.0/24 via 66.11.172.1 dev ipsec0 
192.168.1.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 66.11.172.1 dev ppp0 

ASL2 External interface: yyy.yyy.yyy.yyy
ASL2 eth0_network: 192.168.2.0
ASL2 eth0_interface: 192.168.2.1

ASL2 VPN Routes:
0          192.168.2.0/24     -> 192.168.1.0/24     => tun0x1002@xxx.xxx.xxx.xxx

ASL2 Routing Table:
66.11.172.1 dev ppp0  scope link 
66.11.172.1 dev ipsec0  proto kernel  scope link  src yyy.yyy.yyy.yyy
192.168.2.0/24 dev eth0  scope link 
192.168.1.0/24 via 66.11.172.1 dev ipsec0 
127.0.0.0/8 dev lo  scope link 
default via 66.11.172.1 dev ppp0 

Both ASL boxes has rules to allow any xxx.xxx.xxx.xxx  yyy.yyy.yyy.yyy and 192.168.2.0/254  192.168.1.0/254

Hope this is enough detail.

Roland, the rule to allow traffice between your external interfaces (xxx.xxx.xxx.xxx  yyy.yyy.yyy.yyy) is definitely not necessary. Since these are external, they are not under the control of your ASL. Try taking this out and see what happens.

You wrote you added the rules from 192.168.2.0/254  192.168.1.0/254 on both ASL's. Have you also defined the return ways 192.168.1.0/254  192.168.2.0/254
on both ASL's? If not, try adding these as well on both ends.

Ronald

I'm fairly sure you're right about the xxx.xxx.xxx.xxx  yyy.yyy.yyy.yyy allow rule, I only put it there to keep te live log clean.

On the rules front, yes, I have 192.168.1.0/24 > 192.168.2.0/24 and vice versa on both ASL boxen.

More to the point though, I can happily SSH from 192.168.1.102 to 192.168.2.50, and from 192.168.2.100 to 192.168.1.25... but that's all  i can do... I can browse FTP from 192.168.1.102 to 192.168.2.50, but I only get the top 1k of a file when downloading.  I can tunnel things through SSH and that works.. all this points to a rules problem, however, there is no movement in the filter violation live log when I try to FTP or browse a www server on either segment...

Sounds like a routing issue or a NAT.  You don't want externalA/B->externalB/A rules.  An easy way to rule the internal nets is to make a Net Group containing both internal nets then {internal_nets} ANY {internal_nets} ALLOW.

Do you have a MASQ for general internet?  You don't need any other static routes for the VPN.  Also, you don't want to set QOS or RealBW with PPoE interfaces.

And make sure your internal machines actually have the subnet you think they have and default gateway of the firewall.

HTML issues could also be a DNS problem depending on what the servers are trying to do.

.. was able to play whole AOE2 game from 192.168.1.100 to 192.168.2.179 ... IPSec net-net is working just fine for stuff not defined in NAT... very strange.

How many NAT rules do you have?  The basic set-up would only need one MASQ NAT rule for all the inside users to get to the internet.  Anything destined for the VPN won't use NAT.  Make sure your NAT is specifying the external interface and not ALL.
ex: 
Rule: MASQ
Network: eth0_network__
Interface: Internet_Interface

NAT rules:

DNS   All -> outside_Interface__ / DNS   None   Emu - 192.168.2.50   edit | delete   
  Default masq   eth0_Network__ -> All / All   MASQ__outside   None   edit | delete   
  FTP - Control   All -> outside_Interface__ / FTP-CONTROL   None   Emu - 192.168.2.50   edit | delete   
  FTP - Data   All -> outside_Interface__ / FTP   None   Emu - 192.168.2.50   edit | delete   
  HTTP   All -> outside_Interface__ / HTTP   None   Emu - 192.168.2.50   edit | delete   
  PPTP Masq   PPTP-Pool -> All / All   MASQ__outside   None   edit | delete   
  SSH   All -> outside_Interface__ / SSH   None   Emu - 192.168.2.50   edit | delete   
  X-Server   All -> outside_Interface__ / X-Server   None   Roland - 192.168.2.179   edit | delete   
 
... see anything strange?

Am still at a loss here, any info?  need more details? Can't think of what I might have left out...

Am still at a loss here, any info?  need more details? Can't think of what I might have left out...

Hi Roland,

I am having the precise problem you're describing. Could it be a bug in the version of Astaro we're using?  I'm on 4.000 - what are you using.

Regards  and good luck.  

Unfortunatly you will always be at a loss. when doing a freeswan connection you will never be able to ping the gateway. Therefore I'm sure with FreeS/WAN to FreeS/WAN connection you will be unable to ping either the gatway nor the connecting box. This problem is only with FreeS/WAN. I dont know why. I suggested work around would be to have another computer on each side of the network with the services that you would like to  use and keep you FreeS/WAN gateway just that a gateway between networks. You might want to set up Virtual IP adresses and do DHCP/IPSEC. I'm not sure If this can be done on a FreeS/WAN to FreeS/WAN connection but its worth a try.