Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 1 subscriber
  • Views 3890 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

At a loss - IPSEC

Roland Gaspar
Connected my ASL to another ASL through IPSEC.. htings looked great, ping from my eth0_network (call it net A = 192.168.0) to the other one (call it net B = 192.168.1.0) working both ways, I can ssh from A to B quite happily, but nothing more.  I have rules allowing A  B and externA  ExternB...

I can connect to an ftp server on B from A (and vice versa) and start a down/upload, but it dies after aq few bytes...

Any thoughts?


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to benlutgens
    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?
  • 0 in reply to Guillermo Lovato
    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.
  • 0 in reply to Roland Gaspar
    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
  • 0 in reply to Palantir
    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...
  • 0 in reply to Roland Gaspar
    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.
  • 0 in reply to pablito
    .. 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.
  • 0 in reply to Roland Gaspar
    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
  • 0 in reply to pablito
    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?
  • 0 in reply to Roland Gaspar
    Am still at a loss here, any info?  need more details? Can't think of what I might have left out...
  • 0 in reply to Roland Gaspar
    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.  
Cookie Information Banner