Send/Receive to PRODUCTION server

mfmohlma · #11

We have this issue now. It only appeared after the CUBS update. Is anyone else seeing this?

aebrown · #12

oregonmatt wrote:We have this issue now. It only appeared after the CUBS update. Is anyone else seeing this?

I don't see it on any of our stake or ward computers.

russellhltn · #13

In the past it seems to be linked to changes in the networking. You might want to verify that you're still behind the firewall by trying to go to http://www.gambling.com

Then you might want to inquire if there's been any changes to the firewall's configuration. Do you share a connection with a FHC, FM Group or other church offices?

mfmohlma · #14

RussellHltn wrote:In the past it seems to be linked to changes in the networking. You might want to verify that you're still behind the firewall by trying to go to http://www.gambling.com

Yup. Did that - got the block page.

RussellHltn wrote:Then you might want to inquire if there's been any changes to the firewall's configuration. Do you share a connection with a FHC, FM Group or other church offices?

No. Our DSL modem has been a bit flaky though, and we did have to reset it (again) the morning of the 24th. The other ward's clerk did it. I guess I'll have to check with him if he did anything with the firewall. (I guess I could check with him to see if he sees it in his MLS too...) I loathe to call the help desk this week, but maybe it'll be a nice change of pace for someone to not have to deal with anything CUBS related.

russellhltn · #15

oregonmatt wrote:I loathe to call the help desk this week, but maybe it'll be a nice change of pace for someone to not have to deal with anything CUBS related.

Since it might be a firewall issue, you might call GSD instead.

It's a wild guess on my part, but I'm thinking the message was designed to warn developers when they were straying out of their sandbox, but wasn't supposed to appear to end users. But since you don't want to use separate codes sets, it's triggered by something that's supposed to be unique to the development environment.

I'm guessing that trigger might be the visibility of the development servers - which are normally screened by the firewall.

Since you've had to reset the firewall, I wonder if it reset properly. That would be a call to the Global Services Desk. Not LUS.

aebrown · #16

oregonmatt wrote:I loathe to call the help desk this week, but maybe it'll be a nice change of pace for someone to not have to deal with anything CUBS related.

You shouldn't have to bother Local Unit Support with firewall issues -- anything related to the firewall should be handled by the stake technology specialist calling the Global Service Desk, which is a different group of people.

mfmohlma · #17

Ah, yes. I've never had to call the GSD, and it sounds like I should let my STS take care of that anyway. We've never reset the firewall before, just the DSL modem, but as with anything networking-related anything is possible.

Yes, the message certainly seems like a developer's sandbox type of warning.

Just had a thought - since the VPN was undoubtedly broken when the DSL modem was reset, maybe it didn't renegotiate the VPN correctly. Maybe I actually do need to restart the firewall as well now that the internet connection is stable to give it a chance to re-renegotiate. I don't see how it would hurt. If that doesn't work, obviously a call to the GSD would be necessary.

(Something else to do in all of my spare time. :p)

russellhltn · #18

oregonmatt wrote:Maybe I actually do need to restart the firewall as well now that the internet connection is stable to give it a chance to re-renegotiate. I don't see how it would hurt. If that doesn't work, obviously a call to the GSD would be necessary.

Sounds like a plan. You might look for a VPN light before you start, just to see if it's on/working.

#19

RussellHltn wrote:Sounds like a plan. You might look for a VPN light before you start, just to see if it's on/working.

oregonmatt wrote:Ah, yes. I've never had to call the GSD, and it sounds like I should let my STS take care of that anyway. We've never reset the firewall before, just the DSL modem, but as with anything networking-related anything is possible.

In a recent call to the GSD to help resolve a situation in one facility in our stake I discovered that the ASA5505 can display 4 green lights (including the VPN) and yet still have a problem.

Your idea to reset the components again is a good one. The sequence of the reset should be;

1) Turn the ASA and modem OFF.
2) Power up the modem first.
3) Power up the ASA and wait until you get the VPN lamp, which will be the last light to come on. Patience is required here as it can take up to a minute before the ASA is fully up.

If you still have issues after this reset then I'd notify your STS and have him work with your equipment and the GSD in finding the problem.

aebrown · #20

techgy wrote:If you still have issues after this reset then I'd notify your STS and have him work with your equipment and the GSD in finding the problem.

As an STS, I would appreciate being notified of such a situation no matter what. The STS may well appreciate a clerk helping out with some troubleshooting, but he needs to know of any problems.

I'm sure oregonmatt knows what he's doing, but as a general rule I don't want anyone in my stake touching the components of the Internet connection. They might not do things in the right order. Or they might not do sufficient troubleshooting up front and then cut the connection when it was in the middle of being used by someone else.