Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 2 subscribers
  • Views 12899 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

Knoxvault Online Backup won't start

va3mw
Up to this point, one of my customers was working fine.

Now, I am configuring an online backup that initiates communication to their backup servers.  I use the same vendor at home on the same firewall (other than the rules), so I know it works.

Masquerading works, etc.

I set up Service definition for TCP on their 3 ports (6701:6703).   I've also defined their backup server as a defined DNS host and nslookup works and resolves fine.

I've setup Packet Filtering outbound and inbound for those ports (do I need inbound?).  I've also turned them on.

However, it fails to log in to their server.  In the packet filter, I can see the outbound connection, but not the return.

I've even made the rules number 1 and 2 just to be sure.

I then tried a telnet connection on that port to their site and I don't get any sort of logon/herald (not sure if I should).  I do need to test that once I get offsite.

I know I am missing something pretty obvious, but I am  approaching brain fried mode.  [:S]  I have confirmed with them that they are only using TCP (to the best of their knowledge).

I'm going to wireshark a connection on the firewall to see what I can see as well.

thanks in advance for any advice.

Mike


This thread was automatically locked due to age.
Parents
  • 0
    Could this be an IPSEC issue and I need to add all those rules? 

    What does IPsec have to do with this situation?

    Cheers - Bob
  • 0 in reply to BAlfson
    What does IPsec have to do with this situation?

    Cheers - Bob


    Hi Bob

    Absolutely nothing... I was just testing. 

    I was on the phone with the developer, and all they do is initiate an outbound connection on port 6701, then once that is successful, they go on.  The connection never gets completed.  They don't see me log in.  In the packet filter outbound log, I can see it go out to the correct IP address and the correct port (in green).

    I admit, I know enough about IP at this level to know how much I don't know. 

    As I understand it, the server end then replies on the 'random' port that was provided in the masquerade, correct?  Then, that gets routed back to the NAT'd client.

    Other than a packet filter rule that would specifically block an inbound, is there somewhere else I should be looking?

    Just to be sure and hadn't really messed everything up, I restored back to a week ago, created an Packet Filter Outbound rule for those ports and retested....with the same failing result.

    Anyone want to look at a tcpdump from the ASG?  [:)]

    I looked at the IPS log and nothing jumped out at me.  Is there anywhere else this could be getting blocked?

    Is there somewhere, other than the packet filter, that I can define my host to be fully transparent?

    Again, thanks

    Mike

    (this is smelling like a bug, but the fact that it fails on 1 ASG and not another sort of excludes that).

    In my tcpdump/wireshark on the trusted port, I am getting some packets that say "TCP Dup" and "TCP Out of Order" initiated from the local test machine.
Reply
  • 0 in reply to BAlfson
    What does IPsec have to do with this situation?

    Cheers - Bob


    Hi Bob

    Absolutely nothing... I was just testing. 

    I was on the phone with the developer, and all they do is initiate an outbound connection on port 6701, then once that is successful, they go on.  The connection never gets completed.  They don't see me log in.  In the packet filter outbound log, I can see it go out to the correct IP address and the correct port (in green).

    I admit, I know enough about IP at this level to know how much I don't know. 

    As I understand it, the server end then replies on the 'random' port that was provided in the masquerade, correct?  Then, that gets routed back to the NAT'd client.

    Other than a packet filter rule that would specifically block an inbound, is there somewhere else I should be looking?

    Just to be sure and hadn't really messed everything up, I restored back to a week ago, created an Packet Filter Outbound rule for those ports and retested....with the same failing result.

    Anyone want to look at a tcpdump from the ASG?  [:)]

    I looked at the IPS log and nothing jumped out at me.  Is there anywhere else this could be getting blocked?

    Is there somewhere, other than the packet filter, that I can define my host to be fully transparent?

    Again, thanks

    Mike

    (this is smelling like a bug, but the fact that it fails on 1 ASG and not another sort of excludes that).

    In my tcpdump/wireshark on the trusted port, I am getting some packets that say "TCP Dup" and "TCP Out of Order" initiated from the local test machine.
Children