Knoxvault Online Backup won't start

Mike, does the server have the Astaro as its default gateway?  If not, then you can either put a static route in the server or in the device that's its default gateway.  Or, you could SNAT the traffic from the "Internal (Address)", but that's not as clear down the road.

Cheers - Bob

Hi Bob

Yes, it does (I just left the site... so I am 99% sure).  [:)]  

Seriously, it has to as you can actually surf via that box.

I've just managed to wireshark from a house network (that works) and the store (that doesn't).  I am going to compare them after this Rum and Coke that I just got! 

(Maybe that isn't a good idea...[:D] )

Thanks again,

Another thought.  

Could it be something in the ASG that is intercepting the traffic and then firing it back out?  

Would this be intercepted as FTP traffic and do I need to do a bypass?

(Oh, I did an Internal --> Any --> Any ... but no joy either.

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

You're right, you only need inbound if it's the internal deviceinititating each excange and the on-line service just responding.  In any case, you would see blocks in the packet filter log if the service is sending unrequested packets.

However, it fails to log in to their server.

I guess I'm not sure about where things are relative to the Astaro.

Seriously, it has to as you can actually surf via that box.

That's a valid conclusion if the HTTP/S Proxy is in a transparent mode, but not if the browser is pointed at the proxy in a non-transparent mode.

It seems like an outside shot, but how about the Intrusion Prevention log?

Cheers - Bob

Thanks again,

A few back to the basics questions and level setting.

It fails on more than 1 device (a linux server and multiple windows boxes)
There are no special proxy rules in place for HTTP and we are operating in Transparent mode (would not not only affect port 80 and 443 traffic?)
What other 'rules' would catch traffic on port 6701:6703?
What is the best way to ensure that traffic to this host (the backup host) is totally bypassed by the ASG?

The other strange thing is that on my Home ASG with a somewhat similar setup it works fine.

The ASG at this store is used as a basic firewall and exploiting their deep packet inspection strengths.  Nothing else very fancy (no proxies, etc.).  Just the odd port open for special store applications.

The fact that it fails when I do an outbound Any/Any/Any tells me that we are getting intercepted somewhere else.  I guess I am going to have to do an inbound Any/Any/Any as a test.  However I have done an inbound Any/The host Server and it still fails (I hope that makes sense).

Again, thanks for listening

Mike

A bit more on this.  

I wanted to log onto my home firewall to check a few things (home edition).

Of course, port 4444 was blocked, so I added it to my web surfing rules.  That worked.

On a whim, I added my Online backup ports (6701:6703) to that group.  That failed.

Could this be an IPSEC issue and I need to add all those rules?

It fails on more than 1 device (a linux server and multiple windows boxes)

It's still not clear what's failing.  Is this an internal device that tries to login to an external server, or an external server that's trying to login to an internal server?

It sounds like you're not asking yourself the right question.  When I get hung up like this, I make a drawing with notes and arrows that show what's working.  It just has to be somewhere else than in the Astaro.  When you find it, please post the solution.

Cheers - Bob

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

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.

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. 

OK, so let me put that in my own words to be sure I understand.  This is a software package installed on a server behind the Astaro (the Astaro has a public IP on the External interface).  The application backs up files from the server to a remote service.  In order to begin a backup, the application sends a packet on port 6701 to the remote service.  Correct?

You have defined a service "KnoxVault" = "1:65535 → 6701:6703" and used it in a logged PF rule like 'Internal (Network) -> KnoxVault -> {KnoxVault servers} : Allow'.  You can see the outbound packets passed in the PF log, and there are no blocked packets related to this communication.  Correct?

The KnoxVault site says that the traffic is encrypted; one place commented that this was with SSL.  I would have expected port-443 packets to show up as blocked if that's the case though.

That leaves us with the packets being blocked by the ISP or some configuration issue with the application or that customer's KnoxVault account.

Cheers - Bob