Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - frater

#1
I was able to assign a privilege to a group and made the user "apibackup" part of the group.
The interface is a bit counter-intuitive.
One needs to first create the group and only after editing it is possible to assign it privileges.

If you don't know beforehand it can be done there, it is hard to find out things without a manual.
I knew it had to be possible, so I first created the group.
Only when modifying the group, the "assign privileges" gets unlocked.

I don't like interfaces that "unlock" features when needed. Now that I know this is how it's done with opnsense I will be better prepared in the future...

I need to clean up my script a bit and will post it later on.

But many thanks...
I now have my backup-config working just like the one for my pfsense boxes.
I only need to install the api-backup, add a user and a group "backup"
Then I need to assign the privilege "GUI    apibackup" to the group backup and assign an API key/secret to the user.

#2
Thanks...
I was suspecting this as I could not imagine this to be not working at all.
I've been looking for some hints somewhere but could not find it.

Now you mention that there's something like an API-key, I googled that and found this.
I assume I will have no problem using it after using the API-credentials.
I was not aware of the existence of such a thing as API-credentials in OpnSense.

https://docs.opnsense.org/development/how-tos/api.html

Is there a way to create a user which is restricted to downloading a back-up?
#3
Thanks...

That URL works....   ...in Chrome when I have previously logged in.
It doesn't when I logout.

With wget it gives me "Username/Password Authentication Failed."

So I can't directly use that URL without logging in first.
It seems I'm not providing the credentials.

I am using --no-check-certificate
You use it in your example, but write I shouldn't use it.
I take it as an advice to install a certificate. For now I need to to use it as it's not installed yet....



#4
Thanks for your valuable input...

Can someone give me the correct sequence of fetches that need to be done to get the config through the https-interface?



#5
Quote from: chemlud on March 13, 2020, 01:19:38 PM
How about a cron job along the line

rsync -av --update --partial --append --log-file=$HOME/.rsyncd.log <source> <destination>

?

https://www.freebsd.org/cgi/man.cgi?query=rsync
Thanks, but preferably not. I prefer to pull the config which allows me to have all the code and configuration centralized on 1 server. If I let the router push the config it needs to be configured on both the server as the client.
This means troubleshooting only has to be done on 1 end.. not on both ends.

Furthermore it does much more.
It compares the downloaded config with the latest one and deletes it if it is the same in important parts.
This can't be done elegantly if you push the firmware.
This concept also works for very simple routers.

I pull configs from different routers for over 10 years and I prefer it that way.
It is possible to tweak my current procedure to enable it to work as the one for pfsense does.
I seek help to do that. No alternative ways to do a back-up.
#6
@Fabian

I recently switched to opnsense coming from pfsense.
I have about 12 pfsense in the field and now I added an opnsense.

To back-up the configs of these routers I use an hourly cronjob that fetches the latest config and if it is (about) the same it will throw it away. This way I end up with a list of configs through the years that only reflect the changes.

I have written that script in bash, but only the code surrounding the fetching of the config.
I've seen your example in Ruby, but this language is so unfamiliar to me that I can't use it to create a bash counterpart of it.
I am hoping the reverse is not true and that you are familiar enough with bash and are able to tell me how to convert my code to "opnsense".

Here's the code I use for pfsense which is working to this day:


  if ! wget  -t1 --timeout=10 -qO- --keep-session-cookies --save-cookies /tmp/${IDENTIFIER}_cookies.txt ${WGETOPT} ${PROTO}://${IP}:${PORT}/diag_backup.php | grep "name='__csrf_magic'" | sed 's/.*value="\(.*\)".*/\1/' > /tmp/${IP}-csrf.txt ; then
    echo "Error fetching cookie" >&2
    exit 1
  else
    [ ${HEADLESS} ] || echo "Got session cookie" >&2
  fi

  if ! wget -t1 --timeout=10 -qO- --keep-session-cookies --load-cookies /tmp/${IDENTIFIER}_cookies.txt --save-cookies /tmp/${IDENTIFIER}_cookies.txt --post-data "login=Login&usernamefld=${USER}&passwordfld=${PASS}&__csrf_magic=`cat /tmp/${IP}-csrf.txt`" ${WGETOPT} ${PROTO}://${IP}:${PORT}/diag_backup.php  | grep "name='__csrf_magic'" | sed 's/.*value="\(.*\)".*/\1/' > /tmp/${IP}-csrf2.txt ; then
    echo "Error pushing the session cookie" >&2
    exit 1
  else
    [ ${HEADLESS} ] || echo "Pushed cookie" >&2
  fi

  if ! wget -t1 --timeout=30 -qO ${FNAME} --keep-session-cookies --load-cookies /tmp/${IDENTIFIER}_cookies.txt --post-data "download=download&donotbackuprrd=yes&__csrf_magic=$(head -n 1 /tmp/${IP}-csrf2.txt)" ${WGETOPT} ${PROTO}://${IP}:${PORT}/diag_backup.php ; then
    echo "Error fetching ${FNAME}" >&2
    rm -f "${FNAME}"
    exit 1
  else
    [ ${HEADLESS} ] || echo "Fetched ${FNAME}" >&2
  fi


#7
@mimugmail

i wasn't commenting on what he meant.
I knew what he meant.
I was commenting on what he wrote.
#8
a direct IP connection is still "layer 3".The return address is then the source IP. To describe it as layer 2 traffic is a bit strange.
If I go to another town with my car it doesn't make my car the road it's traveling on, nor does it make me a car.
#9
Starting yesterday I stopped implementing pfsense and switched to opnsense (not 100% sure).
This setup was a dual-WAN setup, like I've implemented many times in pfsense.

There are 2 connections. A cable router and a VDSL-modem in bridge.
As for now the cable router is a NAT router/modem with a "DMZ" toward the opnsense router.

For the VDSL-connection I have a connection to the modem (Vigor 130) and on VLAN 34 of that connection I have a 2nd interface and that interface gives me a WAN-address.

I noticed that port forwarding on the dual-NAT is not working, but does start to work when the VDSL-connection is down.

I have this configuration with several pfsense-routers and have not noticed this behaviour there. I don't mean to imply that pfsense does this better. I have seen things on opnsense that make me believe that multi-WAN is being handled better on opnsense.

One of those features is the ability to designate a gateway as a "default gateway candidate". In this configuration I de-select this for the connection to the Vigor-130.

I have created 2 gateway groups and 1 interface group.

I placed the 2 interfaces with gateways to the Internet in a group named:  "InternetIFS"
The 2 gateway groups have both gateways in it with 1 in tier 1 and the other in tier 2.

I de-selected "Block private networks" on the double-NAT connection, but this does not seem sufficient.

I have created a port 443 forward to an HTTPS-server in the NAT-section for the interface group "InternetIFS".
This is working for the VDSL-connection, but not for the double-NAT connection which has all the ports forwarded to the opnsense router.

Interfaces
LAN:   igb0  192.168,16.1/24
WAN:   igb1 192.168.178.5/24 with 192.168.178.1 as gateway.  ("Block private networks" = off)
Vigor130:    igb2 192.168.1.10  with 192.168.1.1 as gateway.
InternetonVDSL: igb2.34   86.*.*.235 with 86.*.*.129 as gateway. ("Block private networks" = off)

Interface groups
InternetIFS = WAN + InternetonVDSL

Gateways
WanGW4:  192.168.178.1 "upstream = checked"   Monitor IP:212.*.*.166
VDSL:  86.*.*.129 "upstream = checked"
VIGOR130_DHCP:  192.168.1.1 "upstream = unchecked"

Gateway Groups
Failover = WanGW4, VDSL
VDSLwFailover = VDSL, WanGW4


The NAT-rules are created on the Interface group named "InternetIFS"
There is a setting "reply-to" which can be disabled, but this setting does NOT exist for NAT-rules.